Keeping users out while posting

[GregOnline]

Hey!

I have written an application we use here at our work, and it seems to work well. The problem is - the users don't! I pulled an all-nighter the other night because I have one user that thinks the database has to be posted every time she looks at the computer. I am sure I am the only one dealing with someone like this. Haaaaaaaa!

Anyway ----- I am using A5 v4.5, multi-user, and the posting routine is called by using a button on a form. The problem is, this person is posting and posting and posting while others are in the program trying to work. What happened the other day was she posted (who knows how many times) while another user was entering some vital information, and some sensitive data was lost.

Is there a script that could be run from the button that will check to see if the databases are open and active and then will tell the user that the databases are currently in use, and not allow the procedure to continue?

Is there also one that will teach the dangerously intelligent how to be teachable? Haaaaaaa

Thanks,
Greg Williams

[Stan Mathews]

RE: Keeping users out while posting

Did you try testing for being able to obtain exclusive use of the table/s in question before allowing the post to begin.

a_tbl = table.open( "tablename.dbf" , FILE_RW_EXCLUSIVE )

will generate an error if exclusive use cannot be obtained, if I remember correctly.

[JerryBrightbill]

RE: Keeping users out while posting

Greg,

Stan is right about the exclusive test. FILE_RW_EXCLUSIVE will generate an error if a table is open and will lock out other users after it is opened.

One of the big problems with program design is designing for the distructive intelligent, well meaning end user. (sometimes abbreviated "idiot"). I learned years ago that if it can be done, someone will do it. I have one user who regularly finds new ways to "break" a program. At least 75 percent of the development time I have spent on an application for them is designing ways to trap every possible goofy move. And yet, every so often they find a little hole somewhere and then I get a call "I don't know what happened, but..........."

I have almost given up trying to train them. I just force them to do it right or lock them out.

Jerry

[russ Boehle]

RE: Keeping users out while posting

You could also do the posting in field rules, then you won't need exclusive access like with a batch post. You also won't need a button on the form for posting, it'll happen in real time. We used to have problem like this in A4v2 but put the posting in field rules in v6. Saved a lot of aggravation and time.

Russ

[Peter.Wayne]

RE: Keeping users out while posting

unfortunately, i believe that stan's solution does not generate an error for shadowed databases on a network. that's a bug that has been fixed in v5, but i don't think the solution will work in v4 if you use network optimization. you may have to set up a table that keeps track of users as they log in and log out of your application, but if your users just turn off their computers or otherwise fail to follow your logout script, the table will not be updated. alternatively, you can force users off the system before posting by using a method outlined in learn alpha.com.
i don't know of any easy method in v4 to see if other users are on a shadowed database.

[Stan Mathews]

RE: Keeping users out while posting

Jerry,

The only, repeat only, reason it is so hard to design fool-proof software, is that there are so many different kinds of fools.

Stan

[Tom Cone Jr]

RE: Keeping users out while posting


Greg,

Two points jump out at me from your account:

1) It might be worthwhile to track down the specific reason data was lost. What interaction between your posting script and the concurrent data entry led to this? Once this is understood you might see a way to protect against it in your code.

2) If your app is dealing with vital, sensitive information, maybe you need both suspenders and a belt in your design. Consider changing the data entry routines so that input from each workstation is stored locally, before it is written to the server. If an update to the shared server fails, the local copy might be used to try again later. Depending on the application batch updates to the server might be a possibility, too.

-- tom

[Thomas Henkel]

RE: Keeping users out while posting

Greg,

Does the posting NEED to be performed during the day???

If not, remove the button and build an application that runs during off hours.

We do an incredible amount of "batch" processing at night. We do not have th luxury of shutting down our daily operations so that we can perform table and system maintenance.

One of our nightly routines has over 1100 lines of xbasic code to perform maintenance tasks.

We created an autoexec application that we call from a schduling program called "launchpad". Launchpad is reasonably inexpensive. It gives you the ability to send keystrokes to whatever application you tell it to schedule. Our autoexec application has 5 or 6 buttons on it and, depending on the date and time, launchpad "launches" the autoexec application, then presses the appropriate button. This system is so good that it even does work on the weekends.

Alternately, When this person presses the "post" button, check for what time it is, and if it isn't near the end of the day, post a message, tehn exit without posting.

Tom

[Pat Bremkamp]

RE: Keeping users out while posting

The best way to improve any process is to eliminte it!

I used to have an application where I had a transaction file and posted to a main file, but after fighting with it for weeks, I realized that I could enter the data directly into the main file using a form that allowed change, but not entry or delete.

If you have to post, then write your own routine in Xbasic and update the main file after every entry by making it part of the save button. It will happen very fast and shouldn't disturb the other users.