Arthur Fuller
fuller.artful at gmail.com
Wed Mar 13 22:32:00 CDT 2013
In similar situations characterized by lots of users and an assigned number, what I have done is this: Create a table guaranteed to have exactly one row. Store the number of interest in a column in said table. The second someone requests a new number, give it to her and immediately increment the number. Then let the user go about her business, taking lunch in the middle of data-entry if she pleases. It won't matter, she's got her number. The record lock is so quick it's almost not there, and there won't be contention anyway since the first user in gets the lock, and releases it fractions of a second later. HTH, Arthur On Tue, Mar 12, 2013 at 4:53 PM, James Button <jamesbutton at blueyonder.co.uk>wrote: > That I'd agree with > User requests open form = create 'record' and post the use of the number > onto the database table, with an 'empty' marker > Commit > Then present the form with the number for user entry > Take input and commit it, replacing 'empty' marker with 'updated, or > 'deleted' marker > ensure id of actioner and timestamp of entry posted. > That way you have a record of the entry attempt, and the action(s) on that > entry. > > JimB > > ----- Original Message ----- From: "Rocky Smolin" <rockysmolin at bchacc.com> > To: "'Access Developers discussion and problem solving'" < > accessd at databaseadvisors.com> > Sent: Tuesday, March 12, 2013 7:49 PM > Subject: Re: [AccessD] Big Problem & Little Problem - Live Date Tomorrow > > > > Where is that number stored? It should be incremented immediately when >> the >> user creates to the new record. If it's calculated by adding one to the >> biggest existing number, then the record needs to be saved immediately. >> >> R >> >> >> -----Original Message----- >> From: accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com> >> [mailto:accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com>] >> On Behalf Of John Clark >> Sent: Tuesday, March 12, 2013 11:50 AM >> To: Access Developers discussion and problem solving >> Subject: [AccessD] Big Problem & Little Problem - Live Date Tomorrow >> >> I've had this program in the users' hands since last week. They were to >> run >> it through some tests, and we intended to go live on Wednesday...Tomorrow! >> In their testing, they found two things...one that I just didn't think of, >> and another that I overlooked...a problem I knew about at one time, and >> just >> glossed over. In my defense, this is the program, if y'all remember, that >> I >> wrote 3 yrs ago, and they're just now getting around to using...I may have >> even had a fix out there at that time, but have now forgotten about it. >> >> Big Problem first... >> >> When a user goes into this application's main form, they enter a witness' >> name, and at that time a voucher number is created...basically sequential, >> built off the date...if I did one now it might be 130001, the next would >> be >> 130002, all the way to 139999, and then in 2014 the numbers would start >> anew. >> >> During testing two users went in at the same exact time and both began >> entering a voucher at the same time. It assigned 130009 to both of their >> subjects. This is a problem for more than one reason. First of all, we >> just >> can't have it. But, if we could get over it, it only prints the one >> record, >> even though they are both in there. >> >> This number is assigned right away, but it isn't in the DB until the >> record >> input is complete. So, in the minute or two that one clerk is entering >> data, >> another could very well get in and grab the same number...the previous not >> being "dedicated" yet, and the latter would gain the same number. What I >> am >> thinking of doing...I'm trying it as soon as I'm out of this email...is to >> hold off on assigning the number until the record is done. But, I wanted >> to >> put this out there and ask for your advice. >> >> >> Littler Problem now... >> >> The whole purpose of this DB is to create a printed voucher for a witness >> to >> take to the treasurer's dept and get paid for their time and mileage. Way >> back w/I was first doing this, someone right on this very list gave me the >> idea of putting all the text together via code, and then printing out the >> sections of text. This worked awesome actually and I'm happy I went that >> way. But, it my final section it is suppose to include two >> numbers...mileage >> and amt owed. I, for some reason, am unable to mix these...text and >> numbers...type mismatch. >> >> Here is the code... >> >> '************ Setup text for 5th paragraph >> P5 = "I, the undersigned Clerk of Niagara County and the aforesaid court, >> do >> certify that " >> P5 = P5 + [txtWitFName] & " " & [txtWitLName] >> P5 = P5 + ", attended 1 day(s) upon request of the District Attorney and >> traveled " >> 'P5 = P5 + [numMileage] >> P5 = P5 + " miles. Said witness is entitled to a sum of " >> 'P5 = P5 + [curMileage] >> P5 = P5 + "payment in full of witness fees." >> >> The problems come on the 4th...and I'm presuming the 6th...lines. Later, >> when I put it together, the final line of that section reads, >> "Me.lblParaFive.Caption = P5" >> >> I'm sweatin' it a little bit here. I am at the end of my day, and they'll >> be >> running these at around 10:30 AM tomorrow. I'll probably stay a little >> later >> tonight...OT is frowned upon though (don't ask), so I don't know how that >> will go either. >> >> Any help will be greatly appreciated! >> >> Thank you ahead of time...John Clark >> >> Notice: This electronic transmission is intended for the sole use of the >> individual or entity to which it is addressed and may contain >> confidential, >> privileged or otherwise legally protected information. If you are not the >> intended recipient, or if you believe you are not the intended recipient, >> you are hereby notified that any use, disclosure, copying, distribution, >> or >> the taking of any action in reliance on the contents of this information, >> is >> strictly prohibited. Niagara County is not responsible for the content of >> any external hyperlink referenced in this email or any email. >> IF YOU HAVE RECEIVED THIS TRANSMISSION IN ERROR, PLEASE NOTIFY THE SENDER >> IMMEDIATELY BY EMAIL AND DELETE THE ORIGINAL MESSAGE ALONG WITH ANY PAPER >> OR >> ELECTRONIC COPIES. >> Thank you for your cooperation. >> >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >> > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> > Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> > -- Arthur Cell: 647.710.1314 Prediction is difficult, especially of the future. -- Niels Bohr