Well, after battling it out in my own head, as well as a meeting I called for with my fellow programmers at work, and finally my posts to online message boards, I ended up with a solution to my Menu Permission dilemma. My intension was to have the Server.exe take care of the initial menu security settings and then allow the client to make "manual updates" to it. My problem was that in order for the Server.exe to make the initial menu permissions when creating the database, it needed to know what the "current" menu structure was on the Client.exe. Which meant that either the Server.exe had to somehow "dynamically" retrieve the most current menu structure from some outside source, or it had to be hard coded into the Server.exe itself. Needless to say I was not fond of the latter of those two choices. So I started brainstorming (with help) on to what I could design to accomplish our needs. The final idea was to add another field to a "App-System" table found in the database, which would house the version number of the last Client.exe menu structure to be created/updated in the database. Doing this would allow the Client.exe to check the database during load-up and realize that the menu structure stored on the database "may" be outdated. Knowing that the Client.exe currently loading up is newer then the last menu structure stored, the Client.exe would then go through the process of "updating" the menu structure on the database. When it is done, it stamps its own version number into the table, and goes along its merry way.

Of course any good programmer should foresee that this design could cause problems. Specifically if two (or more) Client.exe's happen (by chance) to load at the same exact time. This would mean that those Client's involved, would all be trying to update the same Table at the same time. So, how can we avoid this potential problem? My first though was to create yet another field in the table, a bit field called IsMenuUpdating. Then when one client begins it's update, all other clients will wait until it is completed. Problem is, if I performed a simple "check if IsMenuUpdating = True, if not, make IsMenuUpdating = True else wait" routine, there is still the chance that two or more clients checked the table at the same instant when the fields value was equal to false. So I am still in the same predicament as before...

Now to see if there is a way to implement Pessimistic Table locking on an SQL Server...

---