Alpha4v7 memo field corruption in network environment

[jackb]

With the newest vDos version (05/16/2021) 
we see corrupted memo fields on the network. This will happen randomly without any apparent sign or issue. As an example Station 1 could be entering text in a memo field and save it. Shortly afterwards station 2 opens the memo record and it's blank. All info is lost. If station 2 does not save the record, then station 1 will still see the memo content but if station 2 modifies the empty memo and saves new content, the old memo content is gone for good. This does not happen in the previous version (08/19/2020).

[Jos]

That doesn’t ring a bell. And smells like a file caching issue, but vDos does no caching of its own.

Could you come with some test database so I could try to replicate this happening?

Jos

[jackb]

I could create a database with memo field but don't know if that would be a true reflection of the database we are using in a Linux (samba) networked environment with 212,000 records. I know alpha4 uses caching when it builds the index and there is a setting to write data to disk as the record is entered (which is set to NO currently) but as far as I can remember, this wasn't an issue in previous versions.

[Jos]

It seemingly wasn’t an issue with previous versions, I have no idea what would cause that in vDos 2021.05.01.

If Alpha4 itself optionally caches disk writes, it could be a timing error/mismatch, or related. Even an Windows update...

So I really need some test environment to reproduce this issue.

Jos

[jackb]

Yes. Running 2 weeks now with the previous version (08/19/2020) and no issues. I'll see if I can create a test database with memo field but it may not be representative of my setup.
As a bonus, going back to the previous version, also fixes the right key Alt-M issue. In the new version, only the left Alt-M works in Alpha4v7. The right one is unresponsive. Not a major problem for me since I typically use the left key but it may be a bigger issue for others. The Alt-M key is required to edit memo fields.

[jackb]

I extracted a sample database from my files that I can send you but I don't want to upload it to a public forum. I scrubbed the file as much as possible but there could still be some info there that should not be public. Can you give me a private address to send the files? I can confirm that the error does not happen with the previous VDos version we are using at the moment (08/19/2020).

[Jos]

[e-mail] (change the “a” to a “o”). I use wetransfer.com to send large files, or circumvent blocking of executable stuff.

Jos

[alexwi]

Hi,

Was this issue resolved?

To be clear, I'm not using vDos yet, but an issue with memo fields would be a roadblock in that direction.

Thanks!

Alex

[Jos]

Despite extensive testing, I was unable to reproduce that error with the supplied test database.

So we let it be. Jackb would stick with the previous vDos version, and see if the issue would go away with the next version.

Jos

[alexwi]

Is there any way to contact JackB directly? I'm very interested in know if and how he resolved this issue.

Thanks!

Alex

[Jos]

I informed him of your request.

Jos

[jackb]

I am using vDos2020 (08/19/20). It gives the occasional file error when someone creates a new record and does not save it right away but we can live with that. It's probably a file-locking error as we are multi-user on a Linux network. The memo error also happens from time to time so I was wrong when I said it is limited to the new version. However, it seemed to happen more often in the newer version. I haven't tried any new versions as we can live with the errors. Other than that, I can't really help.