Solved Code not save when at runtime

[MarkK]

I can't help but press Ctrl-S every few seconds (and compile first).

Tip: you can run Compile from the keyboard (and Comment and Uncomment block).

• Put your IDE menus into design view
• Drop a toolbar command onto the main menu
• Customize the name to include an ampersand (&) character preceding the key you want as a short-cut
• Return menus to normal
• Hit <Alt>, release <Alt>, then hit < your short-cut key >

As per the image below, to compile I hit <Alt>, release <Alt>, and hit <L>.

So my "every ten seconds or so" pattern is...
• <Ctrl>+S
• <Alt>
• L

 

[AHeyne]

Thank you @MarkK . I already use this. I'm more or less a keyboard junkie.

 

[Edwin SIEW]

Dear all, I have finally come across a post by someone who seems to be experiencing the same problem that I have. Basically, I believe that Access crash and restart so smoothly that I had no idea that the relaunched instance is locked down by the 'Admin' and after many more hours of work, I may or may not be able to save the app. I am also working on office automation right now and the problem mostly shows up as being blocked by another user, despite there being only I who was working on it. It has taken me a long time to suspect this was due Access restarting itself, but I have no way of verifying it. You know how it is with a random and not infrequent problem with an app you are working on, I have started to dismantle some of the work I have done, test some new scripts until the original codes are barely recognizable, and I may or may not be able to just replace the codes with an original because I would want to keep some of the patchy work. On some lonely, I would be frantically trying to recover the app from the injury I afflicted it with in my attempt nail down the problem.

Anyway, the post I copied from the writer's Facebook brings such relief, I am no longer alone in my experience , and I am not imagining things and am probably still sane. Can anyone shed light on this? I strongly feel it is a Win 11 thing, you know, the particular kind of meddling in other people's otherwise uneventful lives that so characterises Microsoft...

 

[GPGeorge]

Spoiler:

View attachment 122661
Dear all, I have finally come across a post by someone who seems to be experiencing the same problem that I have. Basically, I believe that Access crash and restart so smoothly that I had no idea that the relaunched instance is locked down by the 'Admin'

and after many more hours of work,

Spoiler:

I may or may not be able to save the app. I am also working on office automation right now and the problem mostly shows up as being blocked by another user, despite there being only I who was working on it. It has taken me a long time to suspect this was due Access restarting itself, but I have no way of verifying it. You know how it is with a random and not infrequent problem with an app you are working on, I have started to dismantle some of the work I have done, test some new scripts until the original codes are barely recognizable, and I may or may not be able to just replace the codes with an original because I would want to keep some of the patchy work. On some lonely, I would be frantically trying to recover the app from the injury I afflicted it with in my attempt nail down the problem.

Anyway, the

This is indeed a potential problem and one I've encountered recently.

The solution is to NOT continue uninterrupted coding over an extensive period without regular, frequent saves.

If you are actually working many hours between saves, maybe a different approach would be in order.

• Start Access and immediately make a "pre-work state" backup of the accdb on which you are going to work.
• At frequent intervals--say 3-5 minutes--save your work by
  • compiling the VBA
  • saving everything.
• At somewhat longer intervals--say 8-10 minutes--make another backup.

At worst, you'll lose the most recent changes, changes that are more easily recalled than those from several hours earlier. At best, you'll realize the problem before you've invested hours of work.

 

[Edwin SIEW]

This is indeed a potential problem and one I've encountered recently.

The solution is to NOT continue uninterrupted coding over an extensive period without regular, frequent saves.

If you are actually working many hours between saves, maybe a different approach would be in order.

• Start Access and immediately make a "pre-work state" backup of the accdb on which you are going to work.
• At frequent intervals--say 3-5 minutes--save your work by
  • compiling the VBA
  • saving everything.
• At somewhat longer intervals--say 8-10 minutes--make another backup.

At worst, you'll lose the most recent changes, changes that are more easily recalled than those from several hours earlier. At best, you'll realize the problem before you've invested hours of work.

Yes, you make a good point, thanks. But we all need to get into that deep think state where we basically forget what's around us to do our best work and that's really one of the pleasure doing coding.

 

[RonPaii]

Yes, you make a good point, thanks. But we all need to get into that deep think state where we basically forget what's around us to do our best work and that's really one of the pleasure doing coding.

Once you switch from coding to testing, you will most likely fall out of the grove. But in any case adding a save step in regular intervals will quickly become automatic.

PS: I use source control with Access and make a point to commit changes with each new feature.

 

[Edwin SIEW]

hi thank you for your reply. Yes @The_Doc_Man you're right when i implement a code fix then switching to view mode and then close the form, all the code changes are not saving. so currently what i'm doing right now is to close my access and recode before switching to view mode

...and it is random. Without changing any Access version and when working on the same form and codes, sometimes the code saves, and sometimes not. I know if there is an instance of the application running in the background, I cannot save the one I am working on. With no background application, it is still not saving the code randomly. There is no consistent pattern.

Nowadays, I accept the situation whenever this problem occurs, re-do all lost work doggedly, probably not sleeping or resting for the night, while feeling a knot in my stomach from the rage, yes, a rage, I suppress as I continue to suffer torment from Microsoft Office, Access and Win 11.

 

[The_Doc_Man]

After reviewing this thread, another memory came to me. As an Access DB author/admin, I did a lot of code fixes and upgrades (not always in that order), but the record-keeping requirements of the Navy were such that I had to test one thing at a time and record the results of the work. It was a pain in the toches to track things that way, but a side effect was that the things I did had to be saved singly and tested at least on the test bench. The days of code-until-you-drop were long gone, a discarded relic of my college days. (How I ever finished that program for real-time data acquisition in PDP-11 assembly code, I'll never know.... but finish it, I did.)

Coding should be in limited increments for debug/test purposes - and for maintaining your sanity.

Just one old guy's opinion.

 

[Edwin SIEW]

Once you switch from coding to testing, you will most likely fall out of the grove. But in any case adding a save step in regular intervals will quickly become automatic.

PS: I use source control with Access and make a point to commit changes with each new feature.

Yeah but sometimes you do not want to save it because you are still working it out, especially is you are replacing a huge chunk of codes with a different approach up on some new revelation of how to do it better. So you save your existing codes and test various possibilities in the new approach, and you are getting pretty pleased with what's going on and then everything is gone in a random crash or Access just does not save.

There's one Access problem that's particularly unhelpful to people feeling their way around when coding, and that is in how you are prevented from saving an non-working query.

Some queries are pretty complex, and the more elegant a query looks the more you have to think deep in order to crystallize it to that stage. But you cannot save an non-working query mid-construction. Nope, not allowed to. You cannot save it to continue on it later to attend to an unexpected client call. You cannot save it to avert loss of the query before Access crashes. It is a possibility to cut and paste everything into a Notepad to be saved, but besides duplicating activity, there is also a problem with convenient integrity of developing versions, i.e. you must remember to save the new text file with the query into which ever portable memory or cloud to retrieve it if you work on different workstations. In other words, it vexes the soul. We can live with any difficulty life throws at us but thinking about how these basic annoyances are not addressed as part of the overall Access application after so many versions, updates and new languages they produced, it becomes a tad harder not to grumble.

BTW, there is this thing about anyone who owns a monopoly, be it copyright or a patent, was granted that monopoly with an underlying expectation that the market will benefit. If the market is not satisfied by enforcement of the monopoly leading to a product or service withheld from the market, and no alternative is available within reasonable expenses, that monopoly would become averse to market needs, which destroys the purpose of granting that monopoly. In the UK and thus probably somewhere in the US case law as well, a compulsory licence-as-of-right could be granted by the Courts to the public at large which curtails the enforceability of the monopoly, replaced with a licence fee from the public (not sure how they tax the fee but that's what the Accountant General is for). The market is always king when it comes to IP rights in any capitalistic economy. I am quite sure that Microsoft is unaware of this we will never get to that stage anyway but I sometimes wonder how nice would it be if Access becomes sort of open source and we can all make it better with no worry about it becoming retired permanently.

 

[RonPaii]

Yeah but sometimes you do not want to save it because you are still working it out, especially is you are replacing a huge chunk of codes with a different approach up on some new revelation of how to do it better. So you save your existing codes and test various possibilities in the new approach, and you are getting pretty pleased with what's going on and then everything is gone in a random crash or Access just does not save.

With source control you can branch the FE allowing you to work on new features while maintaining the production FE. When the new feature is complete, merge the 2 branches and rebuild the FE.

 

[RonPaii]

BTW, there is this thing about anyone who owns a monopoly, be it copyright or a patent, was granted that monopoly with an underlying expectation that the market will benefit. If the market is not satisfied by enforcement of the monopoly leading to a product or service withheld from the market, and no alternative is available within reasonable expenses, that monopoly would become averse to market needs, which destroys the purpose of granting that monopoly. In the UK and thus probably somewhere in the US case law as well, a compulsory licence-as-of-right could be granted by the Courts to the public at large which curtails the enforceability of the monopoly, replaced with a licence fee from the public (not sure how they tax the fee but that's what the Accountant General is for). The market is always king when it comes to IP rights in any capitalistic economy. I am quite sure that Microsoft is unaware of this we will never get to that stage anyway but I sometimes wonder how nice would it be if Access becomes sort of open source and we can all make it better with no worry about it becoming retired permanently.

Very little change that anyone can force Microsoft to put Access in public domain. MS Flight Simulator, which in no way competed with other MS applications was not put in public domain when they discontinued it.

 

[The_Doc_Man]

Yeah but sometimes you do not want to save it because you are still working it out, especially is you are replacing a huge chunk of codes with a different approach up on some new revelation of how to do it better. So you save your existing codes and test various possibilities in the new approach, and you are getting pretty pleased with what's going on and then everything is gone in a random crash or Access just does not save.

There's one Access problem that's particularly unhelpful to people feeling their way around when coding, and that is in how you are prevented from saving an non-working query.

I won't quote the whole article, but your comments overlap with working in a true development environment. All of us have our little DBs that we tweak and adjust and occasionally curse because of their intransigence. But once you run into the point of trying to keep a DB usable while simultaneously updating it, you have reached the point of establishing a formal development environment. When that happens, it is a pain in the tail-bone to set up but it saves your sanity.

This is what I did with my U.S. Navy database that tracked server status with respect to published patches and mandatory security alerts. I do NOT think this is the only way to approach this problem, but it worked for me. I will also point out that it is an OPERATION solution to a systemic problem, and the systemic problem is not a bug, but a natural property of ALL projects that develop ever-growing code bases.

I had four folders under a master project folder. These folders were DEV, TEST, STAGING, and PROD. Of these, DEV, TEST, and PROD had a folder for the FE and a second folder for the BE. The FE code and shared BE that everyone used could be copied from, but not executed in, PROD. Only I and my two assistants could deal with (had permissions for) the other folders.

I worked in private folder-tree DEV to fix bugs and add new features. That copy of the DB didn't have to work every day and it was OK if I left it in a shambles at the end of a work day. It had its own BE file that was usually just a recent copy of the PROD DB, though it was fair game for updates if a structural change was coming down the pipeline.

When I was ready to do a serious test of the updated DB, I copied it to TEST and reset the BE links to the TEST DB, usually just another recent copy from PROD unless structural changes were coming, in which case it was a copy of DEV's updated BE file.

When the time came to publish, I copied the successful TEST version to STAGING. That was a special-case folder where I established the final linkages to the PROD folder but until that was done, the STAGING copy couldn't be run because initially, its DB pointed to TEST folders. Nothing ever ran from it except a last-moment verification that the mapping was correct.

I wasn't allowed to do an auto-update (a batch file found in other posts of this forum), but I could and did notify my users when a new version was available that fixed certain bugs or offered new features. When a structural change was coming down the pipeline, I set up some down time and a DDL sequence to adjust the production BE files in a way that wouldn't lose data.

This is an overview and there were more than a few pitfalls along the way, but this worked in my environment. Because the complexity of that environment had grown so much, the more relaxed method of updating an Access DB had STOPPED working.

Each of us must decide for ourselves when we reach that point. I won't tell you what to do. I WILL tell you that you will realize you have reached that point when your hairline becomes negatively affected by your frustrations and your family asks "Momma, who is that man?" when you walk in the door at ungodly hours of the night.