- Local time
- Today, 03:28
- Joined
- Feb 19, 2013
- Messages
- 16,607
that's where popups or using form instances come in handyHandy for me to click one to another instead of opening and closing screens
that's where popups or using form instances come in handyHandy for me to click one to another instead of opening and closing screens
Will read it as soon as I'm back home.@KitaYama - you might be interested in this link - attempts to prevent users from making silly mistakes
Microsoft to block Office VBA macros by default
I don't know if people have seen this but it might affect a number of Access users, so in case it helps to be aware: Microsoft to block Office VBA macros by default It seems to only affect if the application came from the internet, but people do use the web to distribute apps.www.access-programmers.co.uk
Just search for Corruption on AWF.
If so many newbies can break their apps, it definitely means Access has some mayor problem not to prevent the conditions those newbies have made.
2 users can not open the same Excel file at the same time. If multi user on the same FE is the problem why Access doesn't behave like Excel?
Why different users are allowed to open the same FE? Isn't it a mistake in Access design?
Again in my case we don't have multi user on the same FE.
If so many newbies can break their apps, it definitely means Access has some mayor problem not to prevent the conditions those newbies have made.
@The_Doc_Man I hate to take out only one part of a well-explained answer and reply to that section only. But just to answer there's always one way out of a disaster.Earlier, a "car" analogy was used about how manufacturers have to improve safety of the vehicle. But there is no improving the safety of a vehicle being driven by a drunk, angry, callous, uncaring individual. On YouTube you can find videos of police chases where the fleeing suspect reaches speeds in excess of 100 miles per hour (160 km per hour).
Unfortunately it seems for most of you this is not a problem. It's a part of the nature of a database to corrupt.
well, I think it sums it up. If it's because of how a database behaves, there's nothing more to say. I try to keep the rules in mind.Yes, it IS part of the nature of a DB to become corrupted. But we are great followers of the Serenity prayer. We need the skill to prevent the problems we can prevent, the grace to accept the problems that we cannot prevent, and the wisdom to know the difference.
In our recent AUG user group meeting the presentation included a demo of a technique to spawn copies of a form to handle a scenario somewhat similar to what you describe. The form, of course, would be identical so that it wouldn't support different parts of an application, but it could allow a person to see, for example, five different customer's records on five copies of the customer screen, or four different orders on four copies of the order screen, etc. I think Juan plans to make the accdb sample available. Details are in the YouTube video.I came across one client where the boss opened the program, moved to a screen, then opened another etc, etc. When I saw her PC she had 16 instances of the program across the taskbar. "Handy for me to click one to another instead of opening and closing screens" she said. She left the PC on 24 hours a day and before the weekend, no doubt just switched off, without closing them all. She claimed she closed them all first........and we can all definitely believe that can't we? I had to make changes to prevent her, or anyone else from doing that. Just never imagined someone would do it.
I can't remember where I first heard this, but one of my all-time favorite taglines has been, "When I said I built it to be idiot-proof, I had no idea there were that many idiots out there."Not necessarily. There is an old saying I learned long ago... artificial intelligence cannot overcome natural stupidity. (That might sound a bit harsh, but...)
The people who so easily crash things they built are the people who don't bother to learn how to correctly use, design, or implement shared applications. They are like people who jump into the deep end of the swimming pool and then wonder how they have suddenly gotten in over their heads. The idea that Access is a rapid application development tool doesn't stop it from having issues of importance to consider. The part that Access makes easy isn't the most important part. A bad design will hobble or outright break ANY database environment.
Earlier, a "car" analogy was used about how manufacturers have to improve safety of the vehicle. But there is no improving the safety of a vehicle being driven by a drunk, angry, callous, uncaring individual. On YouTube you can find videos of police chases where the fleeing suspect reaches speeds in excess of 100 miles per hour (160 km per hour).
What do you do about a failing project when someone arrogantly says "I will make this work because I know all about coding, we don't need to waste our time on designing anything"? The truth is that coding is between 30% and 35% of most projects of any magnitude or importance. If you don't have at least 40% of your project set aside for detailed design and analysis, you have already screwed up badly.
I can't remember where I first heard this, but one of my all-time favorite taglines has been, "When I said I built it to be idiot-proof, I had no idea there were that many idiots out there."
Again I feel being a broken record but I have seen so many "corrupted Access database" posts in Access communities and I was wondering how easily an Access file MAY get corrupted. I was given several reasons. Shared FE, Multi user, not split databases, using accdb file type as Fe. Even I was given a list of important rules in managing a database (#17). To be true, while I understand everyone of you are correct, I also believe many of those points could have been impediment in Access source code. If multi user on the same FE MAY cause a damage, well, it's easy not to allow opening a second instance of the same FE in read/write mode (just like Excel). They also can change their code not to allow running a not compiled file, or prevent compacting it over a LAN network, or prevent editing the code in break mode.
I wish I could state the situation that well. As a solace, I think I'll resort to quoting you extensively.Again, you are looking at this, not with your eyes open but rather with some level of squinting.
I had a 40-user database, split native FE/BE, users had their own individual copies of the FE, FE was NOT an ACCDE, typically 4 to 8 users actually logged in at a time, and the only time it ever corrupted in five years was when one of my previously enumerated user brain-cramp moments happened, or when we had a network or power event. Invariably, our corruption problems were due to operational procedures, not faulty code, because I tested the bloody hell out of everything I published.
The U.S. Navy had a personnel operation for BUMED (the Naval Bureau of Medical Personnel) that managed scholarships and stipends for medical students who enlisted in the Navy. It was an Access FE, SQL Server BE, and it NEVER corrupted that I know of, even though most corruption is due to FE errors.
I will say it again. Blaming Access for excessive corruption ignores the problem that the application may have been set up in a way that invites poor programming or operational practices. Is Access perfect? No, no, a thousand times no. Does Access cause corruption? It can - but most of the time it is NOT the cause. Poor procedures and poor practices are the usual cause.
You are asking Access to protect you from your own foibles, but I don't know of many systems that actually do that. In my opinion, you are looking for Access to rescue you from your own human imperfections. In my opinion, I would never WANT to program in an environment that thinks it knows better than I do how to program a solution for a given problem. At that point, why would I even be there?
My favourite version of this is, "Nothing can ever be fool-proof because fools are so ingenious."When I said I built it to be idiot-proof, I had no idea there were that many idiots out there."
Now that is true fool ingenuity.. It turns out that one user who took over an application I'd created had decided to open the mdb with Word, just to see it it could be done, or some such thing. He then saved and closed it, transforming the internals to Word mush.