OA LodgeMaster Client Server testing

The Order of the Arrow membership database system is called LodgeMaster, also known as "OALM" once you've said "Order of the Arrow Lodge Master" too many times. I tried out the client / server set up for practice. It works, but there are things to be aware of. Below are many screen shots; I'll talk about them in this beginning text.


Let's see, over 15 images of 50KB each or so, that's 750KB. Should not take too long to download...


Image (1) show what the server screen looks like, once you've switched on the feature. I am not showing the setup screen, but there is a key that is generated which each client will need to enter to connect.

Image (2) shows what a client looks like, after connecting. While the client machine will still have a database running, user screens will be connected to the database on the remote server.

Since clients will use one central database, rather than the distributed databases, I would make sure no client machines enter data except in the server/client connection during an event. Otherwise, no new or changed records on the client machine will be visible to anyone else until after all have synchronized later.

Images (3) and (4) show the error messages if a client machine does not have the server's IP address and current key (which changes on each open and close of the server).

So what about synchronization? Neither the server nor the clients can synchronize to the central database (in the cloud) while either are running remotely. See image (5). Because "all the eggs are in one basket", I would recommend trying take check points during the event, such as late night, early morning, or maybe mid-day. All clients need to disconnect, the remote server needs to be switched to normal mode, then synchronization started. That way, all is not lost should that machine crash, especially since the clients databases have no records of any entries during their remote access time.

Image (6) shows what happens when the server goes back to normal mode.

Most of the remainder of the images were recorded during test scenarios where I shut down either the internet connection, the server, or crashed the client process to see how the client/server behaves. Unfortunately, while one message claims "returning to logon screen" I was never able to re-connect a client process once the linkage dropped.

Stopping the client SQLServer process did nothing to restore a live connection; the MSACCESS process apparently manages the menu screens. That makes sense once you realize the client connects to the SQLServer database on the remote machine.

If the remote server is stopped and started again, a new key is generated, meaning each client will need to start up again with that key.

Some of the error messages are not connection-related, but due to bugs in OALM or Microsoft software. "Invalid object names" seem to be due to broken records inside the database. The "Microsoft Office Access has encountered an error" could be due to a bad call, or just general bugginess. Business as usual in the software world.

Despite these test results, I didn't lose any data or need to reboot either system. Given this will be used in a field situation, with lines of people sometimes waiting for check-in, it's important to practice under adverse conditions to anticipate and avoid problems. Motto of the Scouts, right?



(1)



(2)



(3)



(4)




(5)



(6)



(7)



(8)


(9)


(10)



(11)


(12)


(13)


(14)



(15)


(16)


(17)