Board index » delphi » D6: why does .recno only returns -1after update from D1:

D6: why does .recno only returns -1after update from D1:

Hi,
   I updated an old D1 program where I was using table1.recno and
table1.reccount to display where I was in the database (dBase).  .reccount
works just fine, but .recno only yields -1!  Any ideas?  
Thanks,
Mark
 

Re:D6: why does .recno only returns -1after update from D1:


"MDiluglio" <mdilug...@aol.com> skrev i melding
news:20020218154233.28632.00001472@mb-fi.aol.com...

Quote
> Hi,
>    I updated an old D1 program where I was using table1.recno and
> table1.reccount to display where I was in the database (dBase).  .reccount
> works just fine, but .recno only yields -1!  Any ideas?

I believe the BDE was thoroughly changed from 16-bit to 32-bit version. Back
in D1/D2 days, I did a speed comparison between the two versions, and they
were performing extremely different - D1 was quick on opening a result set
but slow on further data fetching, while D2 / BDE32 was dead slow on first
return of records (but from the on - much quicker).

When RecNo returns -1, it means it's a kind of restult set where the engine
doesn't know the number of records it's gonna return. But I guess you've
figured that out allready.

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Re:D6: why does .recno only returns -1after update from D1:


If .recno does not work does that mean that there is no way to determine where
in the database one is?  The scroll bar is useless (top, middle or bottom)?

Thanks,
Mark

Re:D6: why does .recno only returns -1after update from D1:


RecNo is a very flaky concept in a dataset. Given most modern
applications are mulituser. What was at record x may not be at x after
the next transaction is processed. To move about in a dataset you
should use First/Last Previous/Next. To 'Store' a particular record
use the TBookMark class.
Please keep spamming my email account. I don't mind because I don't read it.
"A bottle in front of me is better than a Frontal Lobotomy" Anon

Re:D6: why does .recno only returns -1after update from D1:


Quote
Bj?rge S?ther wrote:

>- D1 was quick on opening a result set
> but slow on further data fetching, while D2 / BDE32 was dead slow on first
> return of records (but from the on - much quicker).

Also the old 16-bit BDE is a lot faster when doing for instance
brute force, no indexes, SQL-searches. At least with Paradox tables.

I have seen others reporting tests with the 32-bit BDE against
several other competing DB engines. When calculating averages
from several type SQL searches, BDE is almost always the
fastest engine.

But these numbers are nothing, when the old 16-bit technique
rolls in:)

Some years back I did run tests with a 240.000 record, 40 MB
database. Simple searches like:

  SELECT * FROM PARTS
  WHERE PARTNO >10000
  ORDER BY DESCRIPTION

The 16-bit BDE 2.52 was about 20..40% faster finishing these
SQL searches, than the 32-bit counterpart BDE 4.51.

Markku Nevalainen

Re:D6: why does .recno only returns -1after update from D1:


"Markku Nevalainen" <m...@iki.fi> skrev i melding
news:3C743187.5FB6@iki.fi...

Quote
> Bj?rge S?ther wrote:

> >- D1 was quick on opening a result set
> > but slow on further data fetching, while D2 / BDE32 was dead slow on
first
> > return of records (but from the on - much quicker).

> Also the old 16-bit BDE is a lot faster when doing for instance
> brute force, no indexes, SQL-searches. At least with Paradox tables.

> I have seen others reporting tests with the 32-bit BDE against
> several other competing DB engines. When calculating averages
> from several type SQL searches, BDE is almost always the
> fastest engine.

> But these numbers are nothing, when the old 16-bit technique
> rolls in:)

> Some years back I did run tests with a 240.000 record, 40 MB
> database. Simple searches like:

>   SELECT * FROM PARTS
>   WHERE PARTNO >10000
>   ORDER BY DESCRIPTION

> The 16-bit BDE 2.52 was about 20..40% faster finishing these
> SQL searches, than the 32-bit counterpart BDE 4.51.

One difference between the 16- and 32-bit versions, is the fact that with
16-bit, data was actually shared between all applications linking in the
idapi dll's. It may be so that when the .dll was controlling all data access
through a common memory block, one could actually *do* things that
isn'tpossible in 32-bit world, where all data is duplicated for every loaded
instance. Multiuser handling was kind of "pushed one level down"...?

I remember creating a small application that would unload all idapi dll's
upon a crash when working with D1. Then you would need to restart Delphi to
have another go....shared memory....;-)

--
Bj?rge S?ther
bjorge@hahaha_itte.no

Other Threads