 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / February 2005causes of corruption in ACC2003
I ran into corruption troubles with multiuser application (split F/E + B/E) which was converted from ACC97 to ACC2003. The application had worked just fine for five years with 97, but we had four incidents of corruption during the week after converting and moving to Server 2003. One change which seems to have helped significantly was to move to individual copies of the F/E rather than a shared copy as we had done with 97 (I subsequently learned that 97 was more resistant to corruption problems caused by a shared F/E). I was wondering whether any of the following could also be troublesome: - code which places values directly in bound textboxes (I have already replaced the code in several such places with SQL-UPDATE statements) - updating recordsets based on JOINS, particularly when fields in 2 different tables get updated. - updating of LEFT JOINs Incidentally this is an application which I inherited from someone else, and would definitely have done several of the above differently in the first place. Other info: new environment has everyone on Terminal Server (6 - 10 users), previously some individual copies of F/E, rest on Metaframe 1.8 Thanks & best regards Often, you changed a lot more then just a97 to a2003 I recall the story about someone who told me that they took a rope. Of course, they forgot to tell me that a cow was attached to the rope! My point here is that likely changed a lot more then JUST a97. Perhaps you upgraded from win98 to winxp boxes also? (winXP uses a VERY VERY different file system, and also this file system is FAR more COMPLEX in terms of security, as this OS can even attach security settings to a individual file...and win98 has noting at remotely close compared to this kind of stuff). However, all things aside, it may be one of many reasons (luck) why you had no trouble with the a97. However a few things: Did you folks also change something more then just a97? Perhaps new pc's were introduced also? Perhaps a new server also? A few more things: > One change which seems to have helped significantly was to move to > individual copies of the F/E rather than a shared copy as we had done with > 97 > (I subsequently learned that 97 was more resistant to corruption problems > caused by a shared F/E). There does seem to be some supprot of the above, but the standard reocmmned way here is to NOT allow muopliate usres into the same front end, and this advice aplies also to a97. Futher, each users should get a mde. > - code which places values directly in bound textboxes (I have already > replaced the code in several such places with SQL-UPDATE statements) No, I see nothiing in the above that would be a souce of data getting damanged on your network. > - updating recordsets based on JOINS, particularly when fields in 2 > different tables get updated. Again, noting in the above. Remember, when you get corruption, you are talking normally about a hardware situation here, and things like network collisions etc (allow multple people to hit the same front end does cause collsions to increae for example. So, just like a car has a red line of 7000 rpm, it does NOT mean that you can run that car at 7000 rpm all the time. The same kind of applies to the network, and you need to have care and feeding of that newtork! > - updating of LEFT JOINs Again, nothing in the above either.... Certainly well written software that reduces bandwidth and load likely will be more reliable, but the examples you have given don't really hint of anything here. The fact that you ran for years trouble free would seem that now trying to look at a few queries and forms as the source of data corruption is not the fox in the henhouse we are looking for...  SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal Albert, the old setup had a few users with Access + F/E installed locally on NT Wkstn, the rest running on Metaframe 1.8 The application was upgraded to Acc2003 and everything moved onto a new server (Server 2003). Everyone now runs on Terminal Services. Perhaps not a great idea upgrading everything at once, but the vendor insisted (he didn't want Acc97 on the new server) Perhaps you > upgraded from win98 to winxp boxes also? (winXP uses a VERY VERY different I just received news of another damaged record this afternoon. The problem this time was similar to last: the values in numeric fields are waaaayyyy too large (eg instead of values in the 40000 - 60000 range, values are in the hundreds of millions). The memo field also contains garbage. Everyone is on TS, so network or PC problems are ruled out. The problem has occurred in two tables, which gives me some a few ideas about what might be causing it (as in my first post), but I am getting exasperated. Assuming that you network admin is not blowing out users when they forgoet to log off (this will cause prlogems). So, make sure your "office" proeduruesd have nbot hcnaged. You do NOT want to abruitlery terminate users. Perhaps becuase of hte new system, users are NOT loggin off. You might want to add some code to the appciton that kciks users out after 1, or 2 hours of inactivliry. > Everyone is on TS, so network or PC problems are ruled out. Ok, so...either the sserver is going down, or the admin is blowing out usrs (terminaing them). You aboasliery MUST not do that! if the admin is not zapping users, the the final thing to check is the op-locks setting. You can read about that here: > The problem has occurred in two tables, which gives me some a few ideas > about what might be causing it (as in my first post), but I am getting > exasperated. sorry...on a notebook..and bumped the send.... Assuming that you network admin is not blowing out users when they forget to log off (this will cause problems). So, make sure your "office" procedures have not changed. You do NOT want to arbitrarily terminate users. Perhaps because of the new system, users are NOT logging off. You might want to add some code to the application that kicks users out after 1, or 2 hours of inactivity. > Everyone is on TS, so network or PC problems are ruled out. Ok, so...either the server is going down, or the admin is blowing out users (terminating them). You absolutely MUST not do that! if the admin is not zapping users, the final thing to check is the op-locks setting. You can read about that here: http://www.granite.ab.ca/access/corruptmdbs.htm SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal Thanks for your comments Albert. I now have significant evidence as to where the corruption is occuring. It is a form which gets its data from a query on three tables. (I inherited the application from someone else, and would definitely have done several things differently). In one case, one of the key-fields used to JOIN tables was being updated by code which assigned a new value to a textbox. (This code has been replaced by an SQL-UPDATE statement followed by a requery on the form). In a second case, several fields (from two different tables) were being updated, again by code placing values in bound textboxes. This has also been replaced with SQL-UPDATE statements. In the other case, data was simply being updated in nonkey fields, but sometimes another form would be opened (which took its WHERE criteria from the calling form, before the calling form's now-modified data had been saved). While you had mentioned previously that updating a LEFT JOIN should not be a problem, everything seems to be pointing to this situation as occasionally causing a problem. Best regards |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.