Board index » delphi » BDE Replacement to fix fly-away problem?

BDE Replacement to fix fly-away problem?

I'm getting tired of writing work-arounds to get rid of the TQuery
fly-away problem. The problem is that if you do an insert into a TQuery,
the new record just overwrites the current record in the local record
cache and the total number of records doesn't change. The work-around
that I generally use is to set a flag in the TQuery.BeforePost event
which gets set to true if this is an insert, and then I test the flag in
the AfterPost event and close the query, reopen it, and seek back to the
just inserted-record. It's a pain, and it also causes unnecessary
network traffic when you have to do an entire refetch of records every
time you do an insert.

I'm wondering if there is a BDE replacement product out there that
properly maintains internal cursors so I would no longer have to do
this. Ideally, it would be ODBC-based so I can use it regardless of the
database (at the moment, I write apps to talk to Sybase, SQL Anywhere,
Paradox tables, and in the future probably Jet MDBs).

Does anyone have any suggestions?

Chris

--
Chris Cleveland
Genesee Development Group, Inc.
2000 North Racine Avenue, Suite 4100
Chicago, Illinois  60614
773.528.1700 voice, 773.528.8862 fax
http://genesee.net
cclevel...@genesee.net

 

Re:BDE Replacement to fix fly-away problem?


Quote
>just inserted-record. It's a pain, and it also causes unnecessary
>network traffic when you have to do an entire refetch of records every
>time you do an insert.

You got that right. Sorry I don't have an alternative other than to
commiserate.

Re:BDE Replacement to fix fly-away problem?


Quote
>I'm getting tired of writing work-arounds to get rid of the TQuery
>fly-away problem. The problem is that if you do an insert into a TQuery,
>the new record just overwrites the current record in the local record
>cache and the total number of records doesn't change. The work-around
>that I generally use is to set a flag in the TQuery.BeforePost event
>which gets set to true if this is an insert, and then I test the flag in
>the AfterPost event and close the query, reopen it, and seek back to the
>just inserted-record. It's a pain, and it also causes unnecessary
>network traffic when you have to do an entire refetch of records every
>time you do an insert.

Not a solution, but it's worth mentioning that using cached updates instead
of live queries causes the inserted records to remain in place.  The down
side (in addition to having to deal with all the posting stuff) is that the
records remain where they were inserted without flying to where they belong
(based on the order of the table).

This is one of the more significant reasons why I've been using cached
updates.

-- Mark

Re:BDE Replacement to fix fly-away problem?


Quote
Mark Pauker wrote:
> Not a solution, but it's worth mentioning that using cached updates instead
> of live queries causes the inserted records to remain in place.  The down
> side (in addition to having to deal with all the posting stuff) is that the
> records remain where they were inserted without flying to where they belong
> (based on the order of the table).

> This is one of the more significant reasons why I've been using cached
> updates.

I have avoided cached updates in the past because you have to handle the
posting, but also because the BDE uses internally-generated temporary Paradox
tables to store the unposted updates. This means that you have pdoxusers.net
file problems, etc. Do you know of any BDE replacement that can handle cached
updates?

Chris

--
Chris Cleveland
Genesee Development Group, Inc.
2000 North Racine Avenue, Suite 4100
Chicago, Illinois  60614
773.528.1700 voice, 773.528.8862 fax
http://genesee.net
cclevel...@genesee.net

Re:BDE Replacement to fix fly-away problem?


Quote
>I have avoided cached updates in the past because you have to handle the
>posting, but also because the BDE uses internally-generated temporary
Paradox
>tables to store the unposted updates. This means that you have
pdoxusers.net
>file problems, etc. Do you know of any BDE replacement that can handle
cached
>updates?

I am not familiar with any BDE replacement that has cached update
functionality.

One comment, though...   While it's true that it uses Paradox files and thus
requires a .net file, this should not be a big issue.  The .net file is only
an issue when attempting to access shared files.  Since the cached
update-related files are stored in the private directory, there should never
be a net file conflict.  It's true that you need to make sure the private
directories don't conflict, but since the default is to use the C: drive,
that shouldn't be a big deal in most architectures anyway.

-- Mark

Re:BDE Replacement to fix fly-away problem?


Agree.  Any ".net" file issues are easy to resolve by setting
Session.NetFileDir and Session.PrivateDir when your application starts.

V/R
Russell L. Smith

Quote
Mark Pauker wrote in message <7472k0$t6...@forums.borland.com>...
>One comment, though...   While it's true that it uses Paradox files and
thus
>requires a .net file, this should not be a big issue.  The .net file is
only
>an issue when attempting to access shared files.  Since the cached
>update-related files are stored in the private directory, there should
never
>be a net file conflict.  It's true that you need to make sure the private
>directories don't conflict, but since the default is to use the C: drive,
>that shouldn't be a big deal in most architectures anyway.

Re:BDE Replacement to fix fly-away problem?


I believe the latest version of ODBCExpress, version 5, supports cached
updates.

Jamie Burks

Quote
Mark Pauker wrote in message <7472k0$t6...@forums.borland.com>...
>>I have avoided cached updates in the past because you have to handle the
>>posting, but also because the BDE uses internally-generated temporary
>Paradox
>>tables to store the unposted updates. This means that you have
>pdoxusers.net
>>file problems, etc. Do you know of any BDE replacement that can handle
>cached
>>updates?

>I am not familiar with any BDE replacement that has cached update
>functionality.

>One comment, though...   While it's true that it uses Paradox files and
thus
>requires a .net file, this should not be a big issue.  The .net file is
only
>an issue when attempting to access shared files.  Since the cached
>update-related files are stored in the private directory, there should
never
>be a net file conflict.  It's true that you need to make sure the private
>directories don't conflict, but since the default is to use the C: drive,
>that shouldn't be a big deal in most architectures anyway.

>-- Mark

Re:BDE Replacement to fix fly-away problem?


Yes, you could try our TSQLQuery, it does exactly what you want and more...
The only snag from your point of view is that it uses the DBLIB driver so
you will have to test if it work with your databases.

Look at http://component-store.com

Thomas Werner
Component Store Ltd.

Quote
Chris Cleveland <cclevel...@genesee.net> wrote in message

news:36657D13.7280C1E1@genesee.net...
Quote
>I'm getting tired of writing work-arounds to get rid of the TQuery
>fly-away problem. The problem is that if you do an insert into a TQuery,
>the new record just overwrites the current record in the local record
>cache and the total number of records doesn't change. The work-around
>that I generally use is to set a flag in the TQuery.BeforePost event
>which gets set to true if this is an insert, and then I test the flag in
>the AfterPost event and close the query, reopen it, and seek back to the
>just inserted-record. It's a pain, and it also causes unnecessary
>network traffic when you have to do an entire refetch of records every
>time you do an insert.

>I'm wondering if there is a BDE replacement product out there that
>properly maintains internal cursors so I would no longer have to do
>this. Ideally, it would be ODBC-based so I can use it regardless of the
>database (at the moment, I write apps to talk to Sybase, SQL Anywhere,
>Paradox tables, and in the future probably Jet MDBs).

>Does anyone have any suggestions?

>Chris

>--
>Chris Cleveland
>Genesee Development Group, Inc.
>2000 North Racine Avenue, Suite 4100
>Chicago, Illinois  60614
>773.528.1700 voice, 773.528.8862 fax
>http://genesee.net
>cclevel...@genesee.net

Other Threads