Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Strange things are happening
Message
De
06/02/2015 17:21:43
 
 
À
06/02/2015 14:54:31
Al Doman (En ligne)
M3 Enterprises Inc.
North Vancouver, Colombie Britannique, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01614979
Message ID:
01614992
Vues:
47
>>This VFP 6 app has been running since 2001,
>>Last week the client noticed that in the first line of a report (a grouped line) the numbers were doubled.
>>Just the first line. All other lines were OK.
>>A browse of the table showed that the data was correct.
>>After futzing for a while, I reindexed the table and the report showed OK In the preview screen.
>>That's the first time I've had to reindex a table in that app.
>>This particular table is used to house monthly data and is zapped every month when the month is closed.
>>I thought, "Wow 14 years and one blown index.. that's not shabby, is it?"
>>Today, the same client called and said that the report was OK in the preview screen, but when she clicked the print button and printed the report, the first line was doubled again.
>>I got the data here and was able to reproduce it.
>>OK in the preview, doubled when printed.
>>Strange.
>>That's a first for me. I've seen many format differences but never saw a report have a different grouping result when printed.
>>I reindexed the table again and packed it this time.
>>Now the printed version is OK.
>>Any ideas as to what might be going on?
>
>In addition to what others have suggested, on some occasions when dealing with intermittent index problems I've had to:
>
>- Replace the .CDX file with a known good one e.g. from an old backup (or even from your dev environment). Even if it's way out of date, you can then REINDEX to bring it back to date. A similar thing would be to DELETE TAG ALL and manually rebuild the tags, but if the table is part of a .DBC and there are relations set etc. that can cause problems. I've found it's easier just to nuke the old CDX and drop in a new one.
>
>- Check the DBF for the presence of odd ASCII characters, especially CHR( 0 ). I've seen these get injected into tables, usually in character type fields ( Char, Memo etc. ) when workstations crash or get disconnected from the network for any reason
>
>- If they've recently replaced a lot of equipment, hopefully they haven't moved to wireless networking.


Thank you, Al.
We have a utility that does DELETE TAG and rebuilds the CDX from a data dictionary.
Running that and packing the table did the job.
This is an existing Terminal Server installation remoting to a large LAN. Just new workstations.
Anyone who does not go overboard- deserves to.
Malcolm Forbes, Sr.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform