Leslie,

<< You do not need to protect your decision, because it is your call not
mine. >>

Good, I'm glad that we both agree on this.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> <<  You do not need to protect your decision, because it is your call not
> mine.>>
>
> Good, I'm glad that we both agree on this.

Well, i don't agree with this. Tim makes EDB for it's customers not for
him self, so the decisions Tim must take will be upon customer
feedback, right ?

For me even loosing 1 customer makes me very sad!

I want to have happy customers and that's why I'm
writing applications to meet their needs.

Remember that we all get money from them in order
to cover our expenses of our company & families.

Mad Customer = Not good = Loosing revenue
Unhappy Customer = Not good = Loosing revenue

Result: Closing my company because i don't have customers!

That's how business & life works.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< For me even loosing 1 customer makes me very sad! >>

Not if it prevents you from loosing 10 more customers that have twice as
many developer licenses.  That's what you don't seem to understand, and I'm
really tired of trying to explain it to you.  I cannot, in good conscience,
either:

1) Introduce a feature that I *know* will produce performance issues in
larger installations

or

2) Spend an inordinate amount of time on something that very *few* people
ask for, only to ignore more important features that *many* people are
asking for.

Just because *you* want it, does not mean that *everyone* wants it, and
presupposing that you know our customer base better than myself, is
extremely insulting.

<< That's how business & life works. >>

No, business works on the principle that you cannot please everyone, and you
have to pick and choose who you have to say no to.  That's the truth.
Trying to please everyone will simply result in an unfocused product that
manages to do everything, but nothing particularly well.  What good is it if
a product supports accurate scrollbars if you can only use them in 25% of
the actual situations where you need them ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< So, it's a matter of time EDB to be the best RMDBS out there. >>

Maybe, but you've got to give me some breathing room.  These things don't
happen overnight.

--
Tim Young
Elevate Software
www.elevatesoft.com

> Michael,
>
> <<  So, it's a matter of time EDB to be the best RMDBS out there. >
>
> Maybe, but you've got to give me some breathing room.  These things don't
> happen overnight.


Ok Guys, EOF of this discussion!

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Tim Young [Elevate Software] wrote:
> Aage,
>
> << What do you mean by "Firebird's DAC" ? >>
>
> DAC is short-hand for Data Access Components.
>

Of course!
Saying "Firebird's DAC" seems to refer to one specific component set.
Which one would that be?

--
Aage J.

Aage,

>> DAC is short-hand for Data Access Components.
> Of course!
> Saying "Firebird's DAC" seems to refer to one specific component set.
> Which one would that be?
Pretty much any, they all (most of them anyway) come from the same original source base.
IBX ships with Delphi and FIB by DevRace is a more popular brunch from the same source code.
FIB has one very powerful (mostly client) data set component which does everything by
running multiple queries and caching data on client side. IBX's data set(s) are less powerful,
they do a very strange thing to locate a record - run a query against server and in
case of success ignore fetched data and iterate its own result set (thus fetching all records
to the client side) until the record is located. Both cases pretty much render locate unusable.
Just imagine you executed a locate over slow connection on 100000 selection of 10000000 record
table with no proper index. First it will do somewhat slow raw scan on server and then will fetch
those 100000 to the client. You may not have enough patience to see the result over DSL connection.

There's also no record count and the recno is calculated by downloading records to client side.
This is not comparable in functionality or performance to what DBISAM has to offer in this
respect. And I'm sure locate makes way more sense in EDB also.

Regards,
Michael

Michael,

Thanks for the info.  Very helpful.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael Baytalsky wrote:
> Aage,
>
>>> DAC is short-hand for Data Access Components.
>> Of course!
>> Saying "Firebird's DAC" seems to refer to one specific component set.
>> Which one would that be?
> Pretty much any, they all (most of them anyway) come from the same
> original source base.
> IBX ships with Delphi and FIB by DevRace is a more popular brunch from
> the same source code.
> FIB has one very powerful (mostly client) data set component which does
> everything by
> running multiple queries and caching data on client side. IBX's data
> set(s) are less powerful,
> they do a very strange thing to locate a record - run a query against
> server and in
> case of success ignore fetched data and iterate its own result set (thus
> fetching all records
> to the client side) until the record is located. Both cases pretty much
> render locate unusable.
> Just imagine you executed a locate over slow connection on 100000
> selection of 10000000 record
> table with no proper index. First it will do somewhat slow raw scan on
> server and then will fetch
> those 100000 to the client. You may not have enough patience to see the
> result over DSL connection.
>
> There's also no record count and the recno is calculated by downloading
> records to client side.
> This is not comparable in functionality or performance to what DBISAM
> has to offer in this
> respect. And I'm sure locate makes way more sense in EDB also.
>
> Regards,
> Michael

Thanks, I think I understand your previous post better now.
IBX and FIB+ were developed from the original FIB (by Greg.Deatz?), I
think.  IBX seems to work with Firebird, but this isn't really supported.
I don't worry a lot about accurate record counts from large datasets -
they're hardly ever very interesting.  (I think I remember requests for
such a feature on the IBO newsgroup a long time ago)

--
Aage J.