| Subject | Re: [IBO] Re: RecordCount (for IBO v4) (or sooner if you like) |
|---|---|
| Author | Dennis Fantoni |
| Post date | 2000-12-02T14:30:09Z |
I would suggest the sugestion someone else made. Let's have two recordcount
functions. You should probably not call either of them recordcount. Running
a converted app. that was written for paradox/BDE yields real weird results
if it relies on recordcount. Some of the errors are hard to find - it could
be for instance totals and searches done internally in the program that
begin not working entirely correctly.
If we had two recordcount functions - say RecordCountClient and
RecordCountServer ppl. would be forced to decide if they need to rewrite a
piece of code or to let it use recordcountserver (knowing it will be slowing
things down).
Another solution would be not to support recordcout at all, but it's a bit
hard on the ppl. doing the converting. They are forced to change a lot of
queries to select count (*) and instead of qry.recordcount they must do a
fieldbyname('count').asinteger.
I would prefer to have a recordcountserver function. The pieces i haven't
got time or insight into converting right now, could be changed from
recordcount to recordcountserver, and at a later point i could search them
out and fix them.
Right now, i have to search out all recordcount references and reporgram
them - it takes some time.
making some property setting that will make recordcount cout correctly is
too error prone i think. One would have to review the logic of all dataset
access to make sure that property is set "correctly" in all datasets (incl.
those created at runtime).
In short
Remane RecordCount to recordcountClient
Create a new recordcountserver function that counts all records that the
given query would fetch. It's okay if it is slow. It should only be used as
a shortcut to speed up conversion of a non-c/s application.
Make a note on recordcount in the helpfile with a few samples of how to
convert most common usages.
(for-recordcount into while not eot
if really need the count, use query with select count('keyfield') and
fieldbyname('keyfield').asinteger to get the count
with complex queries and/or calls where extremely poor perfomance doesn't
matter - replace recordcount call with recordcountserver.
I think it will be a very fast change for You to code, and i don't think You
should use much of Your ibo development time on fixing up recordcount to be
fast *and* reliable. Let's have a 100% reliable one, and a fast one that
can't count.. but let's have none of them called recordcount. If You opt for
plug&nplay bde compatibillity i'd suggest calling the reliable one
recordcount. Right now we only have "compileabillity" lol.
The recordcount fixing has taken about 70% of the time i've used converting
the application to somehting that seems to work as well as before.
If i have had a recordcountserver i would've had a working (slow) app. a lot
sooner, giving testers more time to find other bugs that might have been
introduced in the conversion process.
Dennis
functions. You should probably not call either of them recordcount. Running
a converted app. that was written for paradox/BDE yields real weird results
if it relies on recordcount. Some of the errors are hard to find - it could
be for instance totals and searches done internally in the program that
begin not working entirely correctly.
If we had two recordcount functions - say RecordCountClient and
RecordCountServer ppl. would be forced to decide if they need to rewrite a
piece of code or to let it use recordcountserver (knowing it will be slowing
things down).
Another solution would be not to support recordcout at all, but it's a bit
hard on the ppl. doing the converting. They are forced to change a lot of
queries to select count (*) and instead of qry.recordcount they must do a
fieldbyname('count').asinteger.
I would prefer to have a recordcountserver function. The pieces i haven't
got time or insight into converting right now, could be changed from
recordcount to recordcountserver, and at a later point i could search them
out and fix them.
Right now, i have to search out all recordcount references and reporgram
them - it takes some time.
making some property setting that will make recordcount cout correctly is
too error prone i think. One would have to review the logic of all dataset
access to make sure that property is set "correctly" in all datasets (incl.
those created at runtime).
In short
Remane RecordCount to recordcountClient
Create a new recordcountserver function that counts all records that the
given query would fetch. It's okay if it is slow. It should only be used as
a shortcut to speed up conversion of a non-c/s application.
Make a note on recordcount in the helpfile with a few samples of how to
convert most common usages.
(for-recordcount into while not eot
if really need the count, use query with select count('keyfield') and
fieldbyname('keyfield').asinteger to get the count
with complex queries and/or calls where extremely poor perfomance doesn't
matter - replace recordcount call with recordcountserver.
I think it will be a very fast change for You to code, and i don't think You
should use much of Your ibo development time on fixing up recordcount to be
fast *and* reliable. Let's have a 100% reliable one, and a fast one that
can't count.. but let's have none of them called recordcount. If You opt for
plug&nplay bde compatibillity i'd suggest calling the reliable one
recordcount. Right now we only have "compileabillity" lol.
The recordcount fixing has taken about 70% of the time i've used converting
the application to somehting that seems to work as well as before.
If i have had a recordcountserver i would've had a working (slow) app. a lot
sooner, giving testers more time to find other bugs that might have been
introduced in the conversion process.
Dennis
----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@egroups.com>
Sent: Friday, December 01, 2000 10:50 PM
Subject: Re: [IBO] Re: RecordCount (for IBO v4) (or sooner if you like)
> > Clear enough - but one thing though, you're talking about a full
> > blown record count - do you mean count(*) from <table>?! That would
> > take an awfull long time if there are a lot of records, right?!
>
> Yes, that is pretty much how the current RecordCount property works with
> TQuery and TTable except worse because it just fetches the records to the
> client and counts them that way in all cases. But IBO has avoided doing
this
> and I plan to actually continue avoiding it. I want it under the
developer's
> control and I want to better reflect BDE compatibility at the same time.
>
> I figure if they are converting a BDE application then they would prefer
to
> have the same behavior wherever possible and now with the flip of a
property
> they can make their datasets much more client/server friendly. But, to do
> this I have to make it behave differently than the BDE did...
>
> Regards,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
>
>
>
>