chris@cayman.COM (Chris North, Technical Support) (05/12/89)
I had a Hypercard database that I had created for some of our information here. We have added some people to our group so we need multi-user access to this info. I would like to know if anyone out there has been able to fake Hypercard into being "multi-user". I realize that you can set it up to be multi-user read, but I would like to have individuals be able to update the stack. (One person could modify the stack while others are out of it, but everyone still has access once that person is done modifying. Any thoughts or similar experiences? -- Chris North chris@cayman.COM Cayman Systems 26 Landsdowne Street Cambridge MA 02139 617-494-1999
american@pnet51.cts.com (Jeff Iverson) (05/13/89)
chris@cayman.COM (Chris North, Technical Support) writes: >I would like to know if anyone out there has been able to >fake Hypercard into being "multi-user". Well, I've done some work in that area, where we have around 20 stacks which are accessed by five machines. The data that is used in these stacks are stored in text files and read in as needed. All of the text files are kept track of and referenced by one 'master pointer' stack. Essentially a user enters a stack, say "Sales Stack" and then inputs a customer number and hits a "Look Up" button. This button begins a sequence of events starting with going to the "pointer" stack and determining whether the customer exists, if the customer does indeed exist it then returns to the calling stack and _quickly_ reads in the text file corresponding to the customer, filling in the bg flds as it reads. If the user makes any changes, it queries to save and then writes the changed text to the disk. One may also create new customer records, this involves updating information on the "master pointer" stack, the user hits a button called "New Customer" and the last customer number is determined and incremented to get the new customer number. All the customer info is written to the fields and when done, the user is queried to save, if "Yes" then, the stack goes to the master pointer stack with the intention of writing the new customer number in the appropriate field. If the cantModify property is set, it means that another user is already accessing the file with write permission. so the script jumps back and forth between the calling stack and the pointer stack until it sees an opening and then sets the usermodify to true, does it's little write and gets out (setting the usermodify to false) UGH! I'm typing this realtime so I don't want to edit it or retype it but make every reference to usermodify above to 'CantModify'. UUCP: {amdahl!bungia, uunet!rosevax, chinet, killer}!orbit!pnet51!american ARPA: crash!orbit!pnet51!american@nosc.mil INET: american@pnet51.cts.com