Joseph,

I can appreciate what you say in regard to IBX + MIDAS being a good
combination these days. It does seem that Jeff is catering heavily to that
arena. I think largely for two reasons, that is where Borland is heading
with data access and its demands are simpler than a direct 2 tier
client/server access GUI application with data bound controls.

I also hear you loud and clear that there is potentially a great market out
there for other development environments. I think it would be an excellent
thing for some people to try doing something along those lines. But, there
are two very good reasons that I am unable, or should I say unwilling, to go
that route.

First of all, I am a Delphi bigot. I cannot imagine myself developing
applications in these other development languages. If I were to support them
this means I would have to develop applications in that arena. I don't want
to do that.

Second of all, I am a loyal provider. I am very careful about making sure I
don't over extend myself in my material ambitions. The last thing I want to
do is spread myself so thin that I cannot continue to deliver to my existing
customer base the support and attention they need to have success with that
which I have already made.

If I am going to make any extensive changes with what I am doing in the
future I am going to go the route of supporting additional databases rather
than additional languages and environments. I am already planning ahead for
how I am going to support a separation of InterBase and Firebird. I
anticipate that at some future time not so distant that I am going to need
to treat them as two entirely different databases. Granted there will be a
lot of consistency, but I want to be prepared for any inconsistency. While
at the same time as doing this, what a great opportunity to introduce an
additional database (it will be IBM's DB2) as well as a TIBOClientDataset
architecture for zero install clients in a briefcase mode and some XML
stuff. I've learned that IBO already has built into its datasets the ability
to do much of this. It probably won't be as fancy as MIDAS in some ways but
to fulfill some basic needs in that area is a good idea I think.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Joseph Alba" <jalba@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, October 23, 2001 10:50 PM
Subject: RE: [IBO] Firebird and IBX


> Jason,
>
> My first choice when in comes to Interbase is IBO. If you note, I added
> that with IBX + MIDAS, there is a danger that so many applications out
> there are secretly languishing from long transactions if they just took
> the word of Borland regarding IBX+MIDAS. I verified the claims and found
> that in fact, with embedded child datasets, the transactions are not
> committed. More amazing is, these fixes were quite easily fixed by me
> (around 20 minutes) and yet, Borland has not detected and much less
> corrected this very crucial fix - with Delphi 5. You and I know what
> happens to client/server databases with long-running transactions (not
> only Interbase).
>
> If you note, I added that this would not happen with IBO+MIDAS because
> in fact, IBO can auto-manage Transactions, and in so doing, overcome the
> crucial MIDAS bug. And your personal support is a lot more reassuring.
> I've been posting my notice and fixes in the Interbase (mers), and the
> reply has always been, Borland will not issue official fixes for Delphi
> 5. Also, I asked if I could send the fixed files to those who asked me
> (or post the fixed files somewhere), and the reply was, I can't. So,
> those who want to fix their files should hand fix it themselves.
>
> So, IBO with or without MIDAS in my opinion is really better. But the
> job specifications for the system(s) I have to do specifies IBX and
> MIDAS because the management reasoned out that all that's needed in this
> is the TIBQuery.
>
> With this IBX + MIDAS and embedded child datasets (in Delphi 5), I can
> say that this is a pretty lethal combination which could explode in the
> face of unwary developers. Effects can range from uncommitted
> applyupdates, and the worse is SLOOOWING down databases or even
> corruption which result from many data entry clients unknowningly having
> long running transactions (which could not happen with IBO's advanced
> transaction management.).
>
> Fortunately for me, I have long since learned not to take Borland at its
> word and verified whether indeed transactions are committed and with
> child datasets, transactions are not committed (to my shock and
> surprise).
>
> It took me around 20 minutes to find the three simple culprits and issue
> my personal bug fixes.
>
> And after issuing these, my system is doing quite well.
>
> In short, what I meant was:
>
> IBO = very good and reliable.
> IBO + MIDAS - very good and reliable.
>
> IBX + MIDAS (Delphi 5 with child datasets embedded) - very lethal and
> unreliable combination because this actually means long running and even
> uncommitted transactions.
>
> IBX + MIDAS (Delphi 5 with child datasets embedded) + Miser bug fixes +
> Joseph Alba's bug fixes - nice enough.
>
> But in this, IBX is not at fault. The bugs are in DBCLient, Provider and
> DB.pas files.
>
> Given the original situation of IBX, I think it is also fair to say that
> Jeff has done a good job in fixing IBX. Pound for pound, IBO is miles
> away from IBX, but at least, Jeff was able to make something which can
> actually be used.
>
> Also, though my remark about Visual Basic sounded a bit tongue in the
> check to Helen, I meant it a bit seriously. I've been doing more and
> more Visual Studio these days, and it is a fact that there is a lot more
> Visual Basic developers compared to Delphi. So, if IBO can be
> COM-wrapped and made ActiveX, it could mean opening a previously closed
> audience. (And look ma... No Borland which kicked Jason aside -
> prefering more inferior products even as Jason offered his own component
> set for consideration).
>
> I really am a Borland lover. But I realized it is a bit wise for me to
> have one and a half feet on the other boat. In my opinion, an ActiveX
> IBO would open millions of previously closed doors to Firebird.
>
> Joseph Alba
> jalba@...
>
>
> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Monday, October 22, 2001 10:21 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Firebird and IBX
>
> Joseph,
>
> > In my case, I was pretty much forced to use IBX + MIDAS by the job
> > requirements. MIDAS + IBX bit me with long running transactions...
>
> What makes you think you cannot use IBO + MIDAS?
> I do support this combination as well.
>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
>
>
> ________________________________________________________________________
> ___
> IB Objects - direct, complete, custom connectivity to Firebird or
> InterBase
> without the need for BDE, ODBC or any other layer.
> ________________________________________________________________________
> ___
> http://www.ibobjects.com - your IBO community resource for Tech Info
> papers,
> keyword-searchable FAQ, community code contributions and more !
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>