You didn't way what your platform was or what your application is written in. Our front end is written in VB and uses UniObjects to communicate with UniVerse. Some I/O is done directly by UniObjects, and some is done using calls to UniVerse subroutines.
I have seen problems like this under two conditions: - File is opened when form is loaded and used repeatedly for reads and writes directly using UniObjects. The form is not modal, so user can access other parts of the application while the form is being used. - Write is performed in one form by calling a write operation in a procedure in another form. Again, the write is directly using UniObjects and the form is not modal. This doesn't happen a lot. We have many, many thousands of writes during a day, and this can happen anywhere from 0 to 10 times. Somehow the file pointers get messed up within VB/UniObjects, and the record gets written to a wrong file (CLIENT-MASTER records get written to CLIENT-CRED-DETAIL, for example). We never see this when the write it done using a UniVerse subroutine call. There is some issue between VB and UniObjects (I have no idea where the issue is, but I suspect it is a VB issue). The best way to ensure there is no file-crossing like this is to open the file every time it is needed by a procedure, do the I/O, then release the file. This seems totally like a waste to me (constantly opening and releasing the file), but I have seen the issue and researched it enough to know that this really is the issue. The forms that follow this rule never have any issues with writing the records in the wrong file. Dick Kryka Director of Applications Paragon Financial Services a Division of Money Management International 303-632-2226 [EMAIL PROTECTED] > Pamela J Robbins wrote: >> They find everything updated, but on checking days later, finds the >> data back in it's original state. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
