Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Serious Bug in REQUERY()
Message
 
 
À
01/08/2003 13:03:47
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00815680
Message ID:
00815973
Vues:
23
Hi Elmer,
The BackgroundFetch = "Yes" could cause numerous problems. Some of them documented in PRB: Problems with Visual FoxPro Driver "Fetch Data In Background" Option mskb Q269881. You can find some others discussed in my posts:
- Re: SqlExec() returns different results Message #808478
- Re: Select statement returns a jumbled table Message #642950


>Thanks Garrett.
>
>So, can I take it from your reply that this BUG in which "Background Data Fetch" returns duplicate rows in the resulting cursor is a well know problem? I have been using Fox since 2.5 and just discovered this recently and had seen no mention of it before. I have searched the MS knowledge base and find nothing about this.
>
>I can reliably reproduce this error by programming in a loop to copy data from all tables in a database using SPT to select * from each table to a cursor and appending back to empty tables that have the same primary key field. It seemingly at random gets duplicate records in a selected cursor when no duplicates exist in the soruce table and the primary key index in the copy table will catch it on the append. It is like the query loses its place during the fetch or perhaps a memory leak of some kind.
>
>I have only observed this on "select *" SPT queries on large tables using a DSN connection where BackgroundFetch = "YES", but this just tells me that this is the only place that I can "prove" that it is happening. Is there a KB article that I am overlooking? Should I report it as a bug with repro code? Can I be assured that Select * on large tables is the only place that this behavior is occuring? I am now concerned that reports that I have used for years and assumed to be correct may actually be reporting invalid data.
>
>Thank you for any assistance you can provide. Or maybe Sergey can jump in here with his legendary searching abilities and point me in the right direction. :-)
>
>Elmer
>
--sb--
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform