Alpha5 Multi-user Users Guide

[Sam Wagoner]

Has anyone come up with a single source user guide for installing and running a multi-user system.

I'm trying to install and test a 3 node ethernet application and have difficulty in putting the whole thing together. I find info on runtime here, installmaker there, network optimization over here with bits about shadows. In reviewing the message board, I find alot of people having problems.

I think the biggest problem is making sure all the various directories (application, runtime, shadows, etc) are in unison but I sure could use a user guide to multi-user environments from start to finish.

[Thomas Henkel]

RE: Alpha5 Multi-user Users Guide

I know of no such document, but if you would like to create one, I think we all would be greatful. Just kidding...

As Tom Cone posted in another thread, pathing is probably your biggest headache. We have a very large (~300) node network, and I needed to have a very specific and standardized pathing routine or I would be going around to ALL of those machines.

First and formost, make sure that the folders for the shared databases are shared for full control by all users.

In my autoexec script, I define locations and drive letters for my shared folders. Using this method, I can just reference the variable pointingto the proper path. If I ever need to move thedatabases, tehn all I need to do is to change the reference in ONE place.

Shadow databases are places in subfolders in the shadow folder within the a5v5runtime folder.

Network optimization should be run to insure the quickest possible load time for your app.

Below is a piece of our autoexec script. This is where we define the variables for absolute and relative pathing for our databases.

dim aa as p
aa= addin.variables()
dim aa.bcbss as P
dim aa.bcbss.access as N
dim aa.bcbss.agency as C
dim aa.bcbss.whereto as C
dim aa.bcbss.wherefrom as C
dim aa.bcbss.level as C
'debug(1)
'aa.bcbss.path and aa.bcbss.ppath set up relative pathing for all scripts.
'This will alleviate the need to hard-code a path into any scripts. We can change it here , and
' it should carry through all of the systems.
dim aa.bcbss.path as C
dim aa.bcbss.lpath as C
dim aa.bcbss.ppath as C
dim aa.bcbss.fpath as C
dim aa.bcbss.drive as C

dim global agency as C
dim Global level as C
dim shared result as C
dim shared userid as C
dim shared passwd as C
dim global formname as C

'set the paths. This is where it needs to be changed for later use.
aa.bcbss.path = "\\percy\a5share"
aa.bcbss.lpath = "C:\Program Files\A5V5Runtime\shadow"
aa.bcbss.ppath = "\\percy\a5share\pers$"
aa.bcbss.fpath = "\\bergen\famis\famisincv5"
aa.bcbss.drive = "O:"
aa.bcbss.agency = trim(lookupc("F",1,"agency",aa.bcbss.path+"\tables\agency.dbf","rec"))
agency = aa.bcbss.agency


Because these variables are in the "addin.variables()" space, They are available throughout my applicartion(s) by my just dim'ing the addin space.

dim aa as P
aa = addin.variables()

Good Luck,
Tom

[drgarytraub]

RE: Alpha5 Multi-user Users Guide

Sam,

I am in total agreement with you. Developing a complete application in a5v5 for a single user is VERY easy. However, the same app does not necessarily work well on a network. There are many issues to consider - and I sure would love to see a document that puts all the relevant information in one place.

Gary

[Sam Wagoner]

RE: Alpha5 Multi-user Users Guide

Tom,

Thanks for your quick reply. Your exec gives me a better insight into developing paths.

I do hope someone from ALPHA5 sees light and develops a user guide. I for one just don't have the knowledge.

Thanks again, Tom

Just crawlng along, Sam.....

[Edward Larrabee]

RE: Alpha5 Multi-user Users Guide

I will be pleased to compile and publish your collected wisdom about the best techniques for configuring and maintaining a multi-user installation.

[BRochford]

RE: Alpha5 Multi-user Users Guide

I use the "Alpha Five V5 Runtime Documentation", it's a 9 page PDF document I got from Alpha. That's all I needed to install a 5 User Installation in beautiful downtown Jersey City!

When I make changes, I load them into the Server, update the Version number by 1 and as each user logs in, their Shadow copy is updated.

Anyone wanting a copy of the PDF, email me at [email protected]

I would attach it to this message, but it is copyrighted & or course I would never do anything like that!
-Barry

[drgarytraub]

RE: Alpha5 Multi-user Users Guide

Hi Barry,

Yes, I agree that this is a useful document for how to set up a COMPLETED application on a network, and as such, should be ONE of the pieces to be included in a comprehensive netwrok guid. But, I also think that the more difficult issues center around locking, etc when many users start banging away at the same tables.

For eg, how to test for in use tables, getting an exlusive lock, etc etc etc.

Gary

[martinwcole]

RE: Alpha5 Multi-user Users Guide

I think Ed has made a TERRIFC offer. I would even suggest we have a tab for it. Imagine the aacumulated wisdom of someone like Finnian.

Enclosed is a simple example of how I deal with incrementing a customer number manually when in a multi-user environment.

When I get time, I have more complicated scenarios I'll try to post - like when a user edits a payment, and the form they use has an embedded browse. If they change any of the values in the embedded browse, there is no practical way for them to "Cancel and Close" as the records in the embedded browse are already changed. So when they edit a payment I first empty and then copy all appropriate records to a temppayments.set. Then if they change any values in the form, change their mind, and hit cancel, I delete all the current records and replace them with the records in the temp.set.

But - if 2 users edit differnt payments, they would overwrite each other in the temp tables, as they are both writing to the same temppayments.set tables.

I'll show how I deal with this, when I get time.

[BRochford]

RE: Alpha5 Multi-user Users Guide

Yes Gary, you are correct, but in my particular application it is 95% data entry. Multiple users, even entering into the same table have never caused any problems at all. Now if I was using an auto-increment number of some kind it would be a little more difficult, as soon as a user presses "Add a New Person", boom do the autoincrement, immediately do a commit() and go on with the data entry.

A POS application gives a few more cases that must be handled.

Hopefully enough users can get enough input together to be compiled into a useful "White Paper".

-Barry

[Sholom Hamada]

RE: Alpha5 Multi-user Users Guide

I'm not very knowledgeable about Alpha Five, but it seems to me that this is such a common scenario (user canceling out after making a change to a one-to-many dataset) that Alpha Five generated screens should automatically take care of it. I have dozens of screens in another system (not Alpha Five) that have to worry about this. It's just so common, it's a shame.

[CALocklin]

RE: Alpha5 Multi-user Users Guide

Barry,

Are you saying that the user is almost never in Enter mode but, instead, you create and immediately commit a new record when they click a "New" button? From that point on they are in Change mode?

[CALocklin]

RE: Alpha5 Multi-user Users Guide

Martin, I like what you do and it generally works well with one exception...

I have one customer who was constantly starting then cancelling records. With your system there would be many "unused" numbers because the number is added in the CanEnter event. Checking their DB for errors used to drive me crazy because they claimed to be losing records and I could never be sure if a number was "lost" or just never used.

This is one reason why the auto-increment routines in the newsletter advocated putting it in the CanSave event.

[George Pelkofer]

RE: Alpha5 Multi-user Users Guide

Hi Sam:

I hate to say it, but...

I think that the real answer to all of the weaknesses of the .dbf file format is: SQL based servers, such as MySQL, and/or PostgreSQL, and/or DB2 and/or ASA and/or...

I guess Alpha version 6 will address some of your problems with multi-user issues and concurrent access and transaction logging, etc.

In my estimation, Alpha realizes the problems with the .dbf format. Why else would the next version be geared toward an SQL engine?

Don't get me wrong... the .dbf file format has gone well above its duty; however, it has hit the wall for many applications.

It's kind of like the internet: everything that makes it good also makes it weak and/or insecure.

A horrible tradeoff, eh?

All said, I'm all in favor of a Multi-User Manual...

George

[martinwcole]

RE: Alpha5 Multi-user Users Guide

Barry, one problem with autoincrement is that it uses the number greater than the highest number in the db. Problem - client says Barry, I want you to put everyone who is "unable to locate", "deceased", and "deleted" in an archive - but, if they walk back in, I want you to be able to reinstate them. Also, please arcive all transactions that are paid-in-full that are over two years old.

Cal, I known only too well what you are referring to, as regards users. My biggest client will occasionally employ someone who has NEVER used a PC before.

I have two levels of logging - the first logs all entries, changes, deletes, etc., especially as regards money, and records both the initial and changed values. This one runs all the time, and I have an adminstrator only form that displays all the entries in descending order, by category, by date, by customer, etc.

Then, I have another one, which I use only when I am having trouble with a machine or operator, and it only fires if it is turned on. It records practically every keystroke. It traps all buttons, most events, choices, etc.

The first one is an audit trail (I have caught two fradulent operators in two years) and it also protects me from users who say "this and that" - as I or the corporate administrator can log on wirh PCAnywhere, and open my audit trail and show them even the time of then day they "did it"

PS: if you assigned the number at the cansave event, how would you display the number on the form?

[BRochford]

RE: Alpha5 Multi-user Users Guide

Hi Cal. Yes, but keep in mind It's a POS application wnand I am assigning Invoice Numbers (or Work Order Numbers). As soon as they press either New Sale or New Work Order, I immediately:
Disable the button pushed (heavy handed users can cause "key bounce" or impatient users can continue to hit the key)
read my Start Table(where I keep the last used numbers) increment by 1,
put it in the new record & commit it
update the saved number in the Start Table
enable the button that was pushed.

Then I know it will not be messed up by another user starting a new Sale at the same time (though it can't be at exactly the same time). You are correct, the new Invoice or Workorder is then in change mode. If they want to Void it, there is a void button. This way I can keep a contiguous Audit Trail.

-Barry