Best practices for converting standalone solution to hosted?

[MSPJ]

Hi - I'm sure this has been asked and answered before, but I could find it by searching.  So I apologize in advance and would appreciate suggestions for resources.

I have a solution I've been developing for years which was intended for single user use in a runtime. I'm creating a multiuser version that will be hosted on FM server.  I'm looking for information on what to look out for and what changes I need to make to avoid problems in that environment.  For instance, I'm already aware of the need to load globals from single record tables with non-global variables.   I assume there must be other things like that to be aware of but I haven't found a good resource yet.

Thanks for your help.

 

Michael

Oh, just to add some details, I expect to have 5-10 users at most. 

[Ocean West]

Hi Michael,

I would recommend adding some audit fields Create/Modify  TimeStamp / Account so that you can review who created or edited the records.

 

[doughemi]

If your workflow requires it, you may also wish to limit access to users based on creator or job function (only access own records, only access dept. records, etc).

[MSPJ]

Thanks both!  Are there any ways that multiple users could "step on each other" if I don't script something in  a particular way?  For instance, I have some scripted searches set up with global fields.  Are globals stored per user session?  So one person's search will not impact the others?  

[Ocean West]

Globals are entirely user and session based - searches will not collied with other users.

Collisions occur when one user has a record locked preventing other users from modifying a record. So instances where you have a scripted process to modify a batch of records a user who has edited the record and remains clicked into a field and usually are on the phone or went to lunch - preventing anyone or any scripted process to access that record - this could be compounded where it locks both a child and parent record. - you can even lock yourself out of a record if you open a new window on the same layout one layout you start to enter data the other window you will get a notice that the record is being edited.

The other less obvious issue is you the developer doing live schema changes - if  you open the manage database and start editing a calculation you essentially can lock the schema. If a user click a button launching a scripted process that creates a record and starts setting a bunch of data in to fields. The New Record function fails but the next steps will continue to insert the data on which ever record they happen to be on. You will need to test for errors and catch them and script accordingly. 

 

another case would be a process to import and update records based on matching fields if users have an open record your import would not be with out errors - identifying which records did not get updated is harder to determine. 

[MSPJ]

Thanks much - this is helpful!