In my current job we are writing Visual Basic applications that do a lot of file processing with files shared among many users. Currently, we are doing some operations where we Open the file in Random mode Write a record to the file Close the file (to force it to write the file allocation table) Reopen the file for further processing. Some problems we are having are 1) If another user tries to access the file in the small time that our code is closing/reopening the file then that person''s app generates an error cause the file is not open for reading/writing. 2) In the event of a power failure we are having some data in inconsistent states because data that was written has not officially been written until the file is closed at a later time. In other cases we are doing sequential processing operations that require us to do things like Lock a Record Write, Unlock record Close, Open, Relock Record(to force actual writing). During this time, if someone else is waiting to lock this current record then they will grab it during our close/reopen phase. This has the possibility of corrupting data because one person may be changing data that does not completely reflect the current state of the system. So far we have found no way to make VB write the actual File Allocation table until the file is actually closed. This is causing issues. I''m pretty sure I once saw a method to force writing without having to close but I can''t seem to find anything about it on the net. We need a way to guarantee that the data is written to the file without having to close/reopen the file or specific records in the file. Any of you guys know how this may be done? Thanks, Webby

From what I am gathering on the internet, this is not really possible. I''ve read that back in VB4 this was possible but since then the developers have started using the C++ methods of file handling in VB and with that they broke the ability to Flush the File Cache off to disk. This seems very strange and is very annoying. Would be infinitaly better (for us any way) to be able to flush the cache without having to release our lock on the file or record.

I''m still hoping that someone here might have a workaround for this.

Thanks,
Webby

Problem with that is this is not a new system. The software has been in use since the early 80s. The developers don''t want to switch over to a database because of all the code the have for file methods. Plus, they would have to start charging a buttload more for the software if it was based on a database because of the liscensing.

Would be simpler to just allow flushing the file cache when necessary. Really makes no sense why they didn''t include this feature in VB 4 5 and 6. It looks like there may be a way to accomplish this with VB.Net and I''ve heard talks about updating from 5 to .net pretty soon. Maybe this will help guide them towards that direction.

Webby