It seems that someone who worked to EMS went to IBExpert and bring with him
the source of Quickdesk... thats explains the similarity.

[]s

Carlos
WarmBoot Informatica - http://www.warmboot.com.br
Interbase-BR - http://www.interbase-br.com

CF> Hi...

CF> I have been looking around at DB Admin tools... and am tending towards EMS
CF> Quick Desk and IB Expert...

CF> Both of these tools look extremely familiar... I assume the code base was
CF> split at sometime or another...

CF> Does anyone have any idea as to the better product or what the differences
CF> are????

CF> Regards

CF> Colin

CF> EMS Quickdesk: http://ems-hitech.com/quickdesk/
CF> IB Expert:http: http://www.ibexpert.com/

CF> -----Original Message-----
CF> From: Jason Wharton [mailto:jwharton@...]
CF> Sent: Saturday, 30 December 2000 4:25 pm
CF> To: IBObjects@egroups.com
CF> Subject: Re: [IBO] IBO advantages over IBX

>> I believe in IBO, though, and I'm adding a couple of comments about what
>> are the areas I think should be improved to gain the favor of IBX users
>> and former BDE developers:
>>
>> - definitely decouple the UI from the data access layer; provide the
>> current UI controls, support and enhance them, but also make it easy,
>> dead easy for anyone to make IBO-aware versions of their controls. Much
>> easier than Borland's DataLinks, I mean. Publish and document a clean
>> and simple
>> interface and have component makers produce IBO versions of their
>> controls. I think something is being done lately in this respect, but no
>> one would think about developing an IBO application with a grid other
>> than the IB_Grid, for example.

CF> I am working towards this. It is actually pretty easy to make a control IBO
CF> aware because I have built so much into the datalinks. I just need to
CF> document it.

>> - remove quirks and peculiarities, and most of all reduce the reasons of
>> incompatibility between versions. I think this is getting better with
>> the latest versions, but I can see it isn't optimal. A few examples of
>> what I see as "quirks" are the behavior of RecordCount in the TDataSet
>> based components, the '::SQL::' prefix in filters, the exposure of the
>> IB bug on stored procedures.

CF> These items are resolved. The RecordCount issue is more correct now than it
CF> was before. It has been brought into harmony with what the BDE users are
CF> expecting and still provides the preferable behavior that I like by setting
CF> a single property.

CF> As for the ::SQL:: issue. I never documented that the Filter property was
CF> for anything other than the syntax that the BDE would allow. Because of the
CF> way I implemented it it made it easy for people to include SQL in there and
CF> get away with it. Then, when I made some additional improvements so that my
CF> filter parser was more thorough and allowed more flexibility it started to
CF> parse the text always instead of using a cheap tactic to see if it could
CF> ignore parsing. Thus, I started messing up those who had been using the
CF> Filter property for undocumented purposes. In order to accommodate this,
CF> instead of tell people "too bad" I opted to add the ::SQL:: prefix. I think
CF> this was a wise move. In short, if you are using the Filter property as
CF> documented there would have been no adverse changes to deal with at all.

CF> As for RecordCount and IBX, I really don't think there is any comparison
CF> there because it simply doesn't work in IBX at all. It doesn't have the
CF> parsing smarts that IBO does and so it either forces you to fetch all the
CF> records into the dataset or deliver an inaccurate value. Did you really
CF> intend to convey the notion that IBX was better than IBO where record counts
CF> are concerned?

>> - give dignity to the TDataSet-based flavor of the components. It is
>> easy right now to take advantage of both flavors in the same app, but
>> your current view seems to be that they are to be used for BDE
>> compatibility only (and I would suggest to rethink the layering:
>> TDataSet compatibility and BDE compatibility should not be mixed, I
>> think), where I know that the option of using out-of-the-box data-aware
>> controls is just as much important.

CF> TDataset has much from the native IBO layer that goes beyond mere BDE
CF> compatibility. I surface as much as I can to them and I think I'm already
CF> doing a pretty good job here. I make it so that you can even access the
CF> internal dataset to tinker around.

CF> What do you suggest I do that I am not already making available in the
CF> TDataset portion of IBO? The greatest benefit of making IBO's TDataset
CF> components TTable, TQuery, TDatabase, etc. compatible is all that Borland
CF> has done to document them applies to IBO. Thus, I have hordes of free
CF> documentation that readily applies to my components there. This is a very
CF> great benefit, not to mention it is so easy for people to move to IBO from
CF> the BDE.

>> - there seems to be plenty of room to make the wrong thing with IBO:
>> just too many stringlists in which to code behavior, as opposed to
>> compiled Pascal code. The TDataSet-based architecture generally appears
>> more fool-proof and with cleaner interfaces in this respect. But I think
>> this is a design personal preference, after all. OTOH, the easiest it
>> becomes to work with IBO, the less time you have to spend in this list.

CF> You probably don't understand the reason there are stringlists they way they
CF> are. Once you grasp the whole vision of IBO in how you approach the
CF> development and design of an entire application you will love the features
CF> that look awkward to you.

CF> I agree that they do allow errors to be accidentally entered and it might be
CF> a little confusing at times tracking some things down to fix them but once
CF> used to it things fall together very quickly. Especially when you discover
CF> how to make global settings.

CF> Also keep in mind that the string lists are only parsed at Prepare time.
CF> Once prepared there are static containers for the pertinent information.
CF> Thus, there is a little bit more resource usage but no loss of performance
CF> by using them. And, in fact, for a large application I dare say that there
CF> is less overall resource usage because so much of your applications settings
CF> can be stored globally instead of spread all over in all the datasets.

>> - improve design-time support.

CF> Agreed. This is always much to improve here. I would like to eventually get
CF> it to where there doesn't have to be so much poking around in string lists.
CF> These really are just intended for raw storage. But, because of how things
CF> are scoped it makes it a little tough to make a GUI that harnesses the full
CF> power of the entire IBO settings model.

>> > Why am I doing this? First of all because I get asked it a lot and

CF> second

>> > because I owe it to the community to give people as much accurate
>> > information as possible so that people can make the most accurate and
>> > informed decisions as to what tools they commit to.
>>
>> As I said earlier, I'll take advantage of any opinions I can find in
>> this thread, but I find your words a little too biased to be "accurate".

CF> Although I am biased, I have been quite careful about what I have said.
CF> What do you feel I am incorrect about?

>> I think this is pretty much acceptable, since you must know very well
>> what you are talking about, but a more comprehensive view of things must
>> be derived from all the opinions I can find in this list and elsewhere
>> (among the rest, one of the things IBX lacks is a strong user community,
>> so it is a little difficult to balance merit opinions).

CF> I think that is fair enough.

>> Also, it would turn to be useful if you would state exactly where IBX is
>> immature and poorly written (if it doesn't take too much time ;-)),
>> because this could serve to improve both IBX (I know you aren't
>> interested in that) and your credibility as an accurate reporter.

CF> John Kaster and I had dinner one night. He thought it was funny how every
CF> time I complained about certain thing in IBX that this was simply used as
CF> their list of things to work on. My comment at the time was, what's good for
CF> Borland I suppose is good for me... I don't feel so much that way any
CF> longer. Mostly because I am starting to feel like Borland doesn't care so
CF> much about the success of me as a third party provider. I do a lot to make
CF> Delphi and InterBase enjoyable and powerful to use. And, what thanks do I
CF> get from them? Well, for starters, I submitted two excellent session
CF> abstracts to present in the Borcon next year. What happened? Both rejected.
CF> Not sure why because I have had excellent reviews on previous sessions I've
CF> presented there.

CF> I have been at this long enough to know when things are right or wrong and I
CF> am not content any longer to sit around and see such a mess made to most
CF> everyone's expense. If I drive the IBX people hard enough to totally rewrite
CF> it so that it is more respectable I suppose that is fine. Either this needs
CF> to happen or they need to concede that it is what it is, poorly architected
CF> and not usable except for simple/lightweight stuff.

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







CF> ######################################################################
CF> Attention:
CF> The information in this email and in any attachments is confidential.
CF> If you are not the intended recipient then please do not distribute,
CF> copy or use this information. Please notify us immediately by return
CF> email and then delete the message from your computer.
CF> Any views or opinions presented are solely those of the author.
CF> ######################################################################