I have included the following error for reference.

The really interesting thing to note is that when I receive this error, exiting totally out of the application and re-entering it resolves the write error. The error is created when trying put an employee name (from a single selection popup) on an invoice. After receiving the write error, exiting out of the application then re-entering the application, pulling up the same invoice and re-selecting the employees name from the popup will successfully write the employees name on the Invoice. Can anyone please explain why exiting the application and re-entering the application makes the difference? I am still getting disappearing data in a posting process and I wonder if this could be the problem?

Thank you,

Janna

Error:

Logical Error Writing 533660 in Table Invoice

–FS10—-

Domain Validation error

The row "533660" contains illegal characters

–or–

The data does not pass validation

patterns specified in the dictionary

ESC to terminate,Break to debugger,Continue?(ESC/B/C)

Janna,

I'll take my shot at one place you might start looking. My shot would be that somehow your code is attempting to write a record mark (one better than a field mark) out in a record string (Remember that the record string, when it gets to the file system level, is going out as the key and the record put together in one string). This record mark proceeds to screw up the internal pointers in the filing system (byte counts between groups, etc) to a point where the error you are getting occurs. The source of the record mark may be in any number of places, but I would offer, based on your description, there is a common (possibly labeled) area, or part thereof, that is getting corrupted with bad data. By logging out completely and back in again, you have reset the common areas and memory. If little or no other processing takes place from the time you log in until the time you attempt the error-producing process, there is likely little that would cause the common area (my theory) to get screwed up.

My suggestion to fixing the problem may prove to be a bit more interesting. The biggest part of it is IF you have the source code to your application. In the source code for the processing that is taking place where the error occurs, see if you can locate the write statement that the filing system seems to be taking offense to. (You mentioned an invoice, so that might be a place to start). Stick a debug immediately prior to that write statement, so as to drop to a debugger just prior to that write. Check the various values involved in the write statement (and likely surrounding statements) to see if you can locate any unusual characters. Since a common area was in my theory, you might see if a common variable is referenced in that area as well. Check its (or their) value(s) as well. Don't forget to look at the key being used for the write as well.

Following up on the common theory, you could test to see if the problem is a labeled or unlabeled common by executing the error-producing code so as to produce the error. Instead of logging completely out, just return to TCL. Then go back in the same program again (minimal other steps in between) and try the same process again. If the error does not occur, your problem may be in an unlabeled common. If the error occurrs again, your problem may be in the labeled common.

One further item to check would be, does the same problem occur on different machine? (Prior check looking at memory problem) Depending on local disk space vs network disk space availability, does the problem occur when running the application on a local drive vs a network drive? (Prior check looking at a disk drive or network communication problem) Do other programs writing to the same file cause similar errors, or is it only this one process? Different programs – any similarities between the programs?

I've probably given you more than you wanted to look at, but I hope it gives you some places to look. If I (or any of us) can be of further assistance, please post away.

Regards,

Eric Drews

Drews Enterprises

www.drews-ent.com

Janna,

FWIW, here's a response to a similar error reported a couple of years ago.

I am inclined to believe your two problems may be related, especially since I don't recall seeing PROTECT.MFS (as Aaron suggests in that link) in your application. It is possible that the memory problems that I was suggesting could also be mangling your data stream and therefore tripping up the internal data validation control as well.

Just my current thought, I'm exploring further into this possibility.

[email protected]

SRP Computer Solutions, Inc.

View this thread on the forum...