Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
User Data for a Report Object Cannot Be Found
Message
De
28/11/2013 15:07:55
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01586848
Message ID:
01588858
Vues:
248
>All of a sudden am seeing a strange sequence of events when attempting to Edit one of my Reports
>
>1. DoubleClick a Text Box and attempt to change an Expression
>
>2. Attempt to Save the changes. Sometimes they change.
>
>3. When I attempt to close the Report Designer, I get an Error Message: "The User Data for a Report Object Cannot be Found" (See Image #1)
>
>4. This is followed by an Error 111 - Cannot Update Cursor {Temp File} because it is Read-Only (See Image #2)
>
>5. At this point The Report Writer and FoxPro will not close and I have to use Task Manager to Close everything.
>
>NEVER seen this before - Help appreciated!

Make sure you don't have any errors on your boot partition. Perhaps not a very likely situation, but it's good idea to check -- errors could cause even more serious problems later on.

Check to make sure the temp folders aren't cluttered with temporary files -- I'd seen numerous situations where weirdness occurs when you've got thousands of temp files in the temp folder.

If the report file is on a network drive, you can see if you get different results if you copy it to a local drive and edit it there. Had similar weirdness that was eventually turned out to be either problem with network cabling, bad switch, or bad network card.

You can try opening the FRX as a DBF then try PACKing it (it is a DBF after all) -- I'd seen situations where deleted records were causing problems. (Obviously you probably want to make a backup copy first)

Have any recent hardware upgrades recently? Once had problem that was eventually traced to a bad memory module. Problems didn't become readily apparent until a few months in (depended on if some crucial bit of data ended up in the bad area of RAM). Occasional glitches would occur, but nothing serious enough -- until system suffered a really hard crash where Windows wouldn't boot (because a critical area of the Registry was damaged beyond repair). After that incident, I've made it general policy to run a memory check over an extended time period after swapping in/out memory modules to make sure we don't have that problem.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform