LiveCode Forums.

Hi,
I'm working on a project that would have a number of independent stacks generate data that would be written to new cards of a separate, single (common) stack. I have two questions about that.

1. In an earlier version of this project I had the multiple, independent stacks merely add the generated data to a common text file. I would occasionally get some scrambled reports, and I was told this was due to the limited abililty of the text file/application to be open for one data transfer, when a second packet would come through. Will changing this to created cards in LC avoid this? My understanding is that almost all database programs would have no problem receiving nearly simultaneous input. What about LiveCode? I'd prefer to stay with LC since I"m somewhat familiar with the language and interface.

2. If I use LC to create this central stack, one that will collect the data as new cards, can that stack be open by another user and continue to receive input, or must it be "closed" in order for the data transfer to work?

I'm hoping I explained that well enough!
NB

It doesn't matter if the file is a text file, a database record, a stack, or anything else -- it is possible for one user to overwrite the data of another user if they are both trying to use the file at the same time. The reason you don't see problems in databases is because they have record-locking built in to prevent that. You can do it yourself with either the text file or a stack, but you need to account for multiple users in your scripts or the data will get scrambled eventually. Two people can't write to the file at the same time.

There are many ways to implement file or record locking. There's an old, but still relevant, discussion in the mailing list archives here:
http://runtime-revolution.278305.n4.nab ... ml#a295095

If you scroll down to David Vaughan's comment, he describes a good way to implement record locking in LiveCode. Basically his stack writes a small file to the server that indicates the stack/file/whatever is currently in use. When another user wants to input data, the app first checks for that file. If it exists, it keeps checking until the file is gone. When it knows it has clear access, it writes its own ownership file so that other users can't interfere.

Since write operations are generally short and therefore pretty fast, there's usually not much lag and little waiting. If you are saving a huge stack to a remote server it can take longer, but usually that isn't the case. A smallish text file would be very fast.