I'm not sure exactly what's happening or if it's a default setting, but PHPStorm seems to be auto-saving files to some sort of buffer if I have not actually saved the file yet. I can close the editor and open it back up to still see unsaved changes, or perhaps it actually saves the changes on exit, I'm not sure which.
I often close the editor and re-load a file when I'm not sure what changes may have transpired since I last opened the file to make sure I don't save unintentional changes, but I can't do that with PHPStorm autosaving or whatever it's doing.
You cannot disable such behaviour -- auto save is one of the core functionalities that this IDE relies on and can be triggered at any moment in time.
You can use Local History to restore file to a previously saved state.
https://youtrack.jetbrains.com/issue/IDEABKL-6460
P.S.
If you will give it a bit of time (few weeks, month -- depends on person and habits), you will get used to it just like many other people who using this IDE.
From this particular comment:
Auto-saving is built in very deeply and many IDE features just won't work without it (e.g. compilation, running, etc). For reverting unwanted changes there's VCS, Local History and Undo.
Currently we don't plan to add a possibility to disable auto-save.
Maybe this is what you're looking for?
To enable preserving temporary files while saving changes
In the IDE Settings section of the Settings dialog box, click General.
Select the Use "safe write" check box.
Note that if this check box is selected, modified file will be first saved as a temporary file. If the save operation is completed successfully, the temporary file will renamed, and the original file will be deleted.
Related
I am building an application that connects to a mysql database. I set up the data connections and data source (data set) and have begun working on development, going back and forth between adding tables and views to the database and adding forms and components to the application.
I have up to now used the "Configure Data Source with Wizard" wizard to refresh the dataset in the application. Sometimes it takes a couple click throughs to get it to fully load the changes, but that's not the end of the world.
Today, without me knowingly changing anything, when I click on the wizard button, the frame of the wizard opens and closes instantly.
My data is accessible, and the parts of the application already developed work just fine, but I don't know how to add new tables and views to my project. My worry is that something went screwy in one of the auto generated dbDataSet.* files.
I'm happy to provide more information if that will help.
To answer my own question for whomever comes here next:
I came across this solution:
https://stackoverflow.com/a/4749044/7640114
It links to a microsoft.com page that is no longer available, but copies the relevant information. Finding the corresponding files is not hard, but knowing what the wrong Provider is may not be so simple.
Mostly because of a lack of patience, I just went with the second option and deleted the entire folder, which may have been overkill. It worked, and I have access to the wizard again and can continue development, but it also wiped out my workspace layout which I now have to rebuild from my memory.
Win some/loose some. In the end, I suggest being more delicate and removing lines of code from DefaultView.SEView first, and then moving on to trying to delete the file and the folder if nessasary.
I was using an Access file a colleague of mine created. They run it without issue on their computer all the time, but when I tried running it on mine, without modifying it, I had a value prompt window come up that isn't supposed to.
I think there's some sort of auto save feature on this file because even after closing it without saving, this message shows up and I'm no longer able to run the macro within the Access file. This file is stored on a shared network drive and file history isn't enabled on this drive nor on my machine. I'm not too familiar with Access and my colleague is on leave for some time. No one else seems to know Access very well either. Is there a way than I can restore the file or the queries/macro inside it to how they were before I opened it?
The basic answer is No. If something really was changed, there is no automatic history that can be used to recover changed settings or macros.
I realize it doesn't help to say anything now, but I am very surprised if there are no backups for the shared network drive. Is there no IT personnel that can assist? Regardless of whether or not you can get the file working, I would immediately make your own manual backup of the Access database file(s). (As long as you have a backup... or even better multiple backups, Access files can simply be restored from the original using file copy and paste.)
"Autosave" is an understatement with Access, because unlike a word processing document or spreadsheet which can be held completely in memory, a database file is constantly updated. There is no in-memory context for the database file as a whole. Access will almost immediately update the file once it is opened, simply because it manages things like file locks, etc. The database may have an Autoexecute macro or other code that runs automatically, but this may be accompanied by security prompts, especially if you haven't opened it on that computer before. For standard forms, changes to data on a form are saved to disk immediately and no "Save" button is required. Certain aspects of the database file should not changed unless explicitly told to do so, and these are usually design aspects not change accidentally.
When working with an Access .accdb, every time I open the file, I see that the 'date modified' in the filesystem changes to now. This makes me nervous. I want it to stop.
I can't be the only person who has ever saved a working db, and opened it a few weeks or months later to an error. Sure, I probably have backups, and backups to my backups, and table data saved separately from my code, and version history taking up multiple gigabytes of the filesystem or in emails or where ever... but it still makes my heart jump a little whenever I see the date modified update on open, when I haven't touched the DB in some time.
Have I flipped a switch somewhere that makes it do this? Is this expected behavior? How can I stop it?
To replicate this, create a new accdb, save and close. Put something in it, nothing, or close it only a second after creating it. Open an windows explorer for the directory the accdb is saved in, and note the date modified value. Open the file at least a minute after the displayed date modified file. alt-tab back to the explorer window, and you see the date modified has changed.
That's the default behaviour, even with a native Access MDB file. They don't work like a normal file that you have to explicitly modify to update the date - it does some things when you open it up, whether you want it to or not.
Just did a quick test - if you set the database file to read-only, it doesn't update itself.
I construct my MS Access Applications into front end and a back end. The Front end database is made up of all the the application objects like the Queries, Forms, Reports, and Modules. The back end database is made up of the tables and links to other data sources.
Many people consider this a Microsoft Access Generally Accepted Best Practice.
So much so that Microsoft includes a Wizard to do the split for you. Shown here
10 Reasons to Split an Access Database
Once the database has been split, It makes is a whole lot more manageable. The Front End can be marked read-only. The Back End remains writable.
Recently I submitted a file to Perforce as “add” (a new file).
Then I submitted several more changes to it.
Now I realize that the original “add” should have been an “integrate” because the file is really a copy and modification of another, existing file.
Is there a way to add the integration link after the fact?
If not, what is the easiest way of doing this? If we obliterate all the affected changelists, and then re-submit them but with the correct integration history, will that work?
Just talked to Perforce Support on the phone. The answer is no, you cannot “change history”. However, the recommended course of action is to:
Take a copy of each change made to the new file(s)
Obliterate all the added files that should have been an integrate
Re-submit each change that was made
It may be possible to generate Perforce journal (database) records that put the missing data in place. These are plain text entries that are replayed into the live database by a system admin. The database schema is documented: www.perforce.com/perforce/doc.current/schema
You'd need to be very careful and work with Perforce Support while doing this, and try it on a test system first. It's normally not worth the effort.
I have a front-end Access 2007 apllication which talks to MySql server.
I want to have a feature where the application on the user's computer can detect that there is a new version on the network (which is not difficult) and download the latest version to the local drive and launch it.
Does anybody has any knowledge or exprience how this can be done?
Thanks
Do you actually need to find out if there is a newer version?
We have a similar setup as well, and we just copy the frontend and all related files every time someone starts the application.
Our users don't start Access or the frontend itself. They actually start a batch file which looks something like this:
#echo off
xcopy x:\soft\frontend.mde c:\app\ /Y
c:\app\frontend.mde
When we started writing our app, we thought about auto-updating as well and decided that just copying everything everytime is enough.
We have enough bandwidth, so the copying doesn't create any performance problems (with about 200 users).
Plus, it makes some things easier for me as a developer when I can be sure that each time the application is started, the frontend is overwritten anyway.
I don't have to care about auto-compacting the frontend when it's closed (and users complaining that closing the app takes too long...), and I don't have to deal with corrupted frontends after crashes.
#Lumis - concerning the custom icon:
Ok, maybe I should have made this more clear. There is only one batch file, and it's in the same network folder as the frontend.
The users just have links on their desktops which all point to the same batch file in the network folder.
This means that:
future changes to the batch file are easy, because it's only one single
file in one central place
we can change the icon, because
what the user sees is a normal Windows link
(By the way, we did not change the icon. Our app is for internal use only, and I'm working in a manufacturing company, which means that all but very few users are absolutely non-technical and couldn't care less about the icon, as long as it's the same on all machines and they know how it looks like so they can find it quickly on their desktop...)
Tony Toews has one: Access Auto FE Updater
It appears to be free, but I'm not 100% sure.
Lumis's option is solid, however if you want to check the version and only copy the database when their is a new version, have a 'Version' field in a back end table, and a 'Version' constant in a front end module. Keep these in sync with each new production release. Compare the table version against the version in the module when the main form of the front end database opens.
If they don't match, have the database close, but have the database call a batch file as the last bit of code to run as it's closing. The database should finish closing before the batch file begins it's copy process. If needed, place a minor delay in the batch file code just to be sure there are no file locking issues.