Fields showing errors

[Missinglinq]

I have done it this way before for 2 db's that are used by 20+ users for about 10 years without any problems related to sharing a single FE.

Sorry, but having multiple users sharing a single Front End, on a network drive, is the sure way to repeated episodes of corruption, speed and timing problems, and all manner of strange, odd and curious behavior!

Being in forced retirement, I spend 8-10 hours a day here and on other Access forums/newsgroups, and over the past ten years have seen literally dozens and dozens of reports of split databases, using links to a single Front End, causing these kinds of problems, as well as massive data loss! The really insidious thing is that this kind of setup can work for extended periods of time (the record time, BTW, for running without problems, then 'suddenly' going bad, was slightly over 20 years!) before the troubles begin! But once it did, it became chronic, occurring over and over and over again...until the sharing of the Front End stopped! But if you don't mind having this problem, or losing data repeatedly, go right ahead and keep on sharing!

Also, Return Without GoSub is basically what the Access Gnomes assigns to any error that they can't figure...and never, in my experience, has the error actually been Return Without GoSub!

Linq ;0)>

[Micron]

No apologies required. If not in this thread, I have posted elsewhere that I wouldn't continue to design this way. If it acts up at the 20 year mark, they'll just have to drag me out of retirement for a short period, so it's a type of job security! I keep in touch with those people, and unfortunately, they always tell me that it's still working as normal.
Return Without GoSub is a hold-over from BASIC (if not earlier).

[Micron]

Well, as I mentioned, I cannot replicate your problem. The only advice I can offer in that case is to try things like removing all but one of the fields in your calculation and test the opening as many times as you think appropriate, based on your current experience. Then add them one at a time and repeat and see what happens. That might not be conclusive in itself, so if the problem occurs with say, 3, then does it matter which 3? More testing...
Last and maybe not least, I have read where fields with default values can cause this error when the default is a property of the control and one is dealing with a new record, which you are. However, your defaults are a property of the table. Perhaps the anomaly can be extended to default table values as well, so my other guess would be to remove the defaults from the table fields and if it's not just a matter of users being too lazy to enter something, then find another way to enforce data entry on those fields after you've had a chance to test with no default table field values.

[koncreat]

I moved the FE to each users desktop instead of having users use shortcuts and it seems to have fixed the errors.

[Missinglinq]

It's always difficult for people who have seen a database work fine, sometimes for years on end, and then go pieces, to believe that it can do so because of sharing a Front End!

Glad you got it fixed!

Linq ;0)>