I have an SQL file containing several commands, when I need to make a correction to my application database that the application can't yet do, I use DBVis to select and execute the command I need (e.g. to delete an incorrect entry). Problem is, the button to run the whole page is right next to the button to run a selected command. So I just dropped and re-created my table, losing all my data. Is there a way to undo this?
I'm looking to either 'undo' each command until I get back to the right place, or revert back to yesterday, where I know everything was correct.
Thanks!
Yes, you can if...
your administration tool did set autocommit=OFF by default, you can
just execute a ROLLBACK (or just shutdown your administration tool)
If latter doesn't work, check if your binary log was enabled, and restore with mysqlbin log tool
If none of the above mentioned solution works, use your (probably not existent) backup for restoring
The company I work for uses a really odd program that essentially adds a skin to Access.
In fact, it's so much like Access that if you open up the program and watch the connection with the Access db, you can see the .ldb pop up.
I built a macro that's supposed to automatically run when the database opens but when the program is opened, it acts as if the database DIDN'T open even though I can see the .ldb file appear.
How do I go about fixing this?
I've been asked to make some changes to an access app, which looks easy enough to do. The data and the code reside in one file. The trouble is while I'm working on a copy of the file from some point in time the production file keeps changing, the plant operates 24/7. I'll need to make a patch to quickly apply to the production file so they can do an immediate switchover without shutting things down.
Is it possible to make a code patch this way in access, so I don't have to type my changes in all over again?
Otherwise, how can I best split the code and the data schema from the data, so I can work on as much code as possible that is independent of the data growth?
Thanks.
I found the wizard that splits a single access file into a front end and back end file. Now I can update the front end file whenever I want to without losing the latest data.
In my case, I had to hold the shift key when opening the database to bypass the macro hiding the menus from the production users.
I came by this page and was thinking about the best method to distribute my VbaProject.OTM file (located into %appdata%\Microsoft\Outlook\) to a bunch of ~30 users at my office. Is it better to simply copy/paste the OTM file onto the network and then copy/paste it back to all users' computers (manually or with a .bat) OR would it be better to use the method described in the link above to generate a OPS file and import it back with Proflwiz.exe? What's the difference?
We are all on Microsoft Office Outlook 2003 actually, we might upgrade to 2007 one day but still years from now.
Finally came up with some elements to deploy a Outlook VBA Project. There are a lot of ways to do this, but the easiest way to do so without installing anything and keeping the same methodology would be to run a OTM file directly from a server. I found out that the process outlook.exe has a parameter altvba that allows to specify another path to run the OTM file from. Here is en example:
outlook.exe /altvba "\\myServer\myFolder\myFile.otm"
This allows me to update only one file to get all computers updated. Obviously, if the file is big and the server's ping is on the high side, it may delay the launch of Outlook. The other problem with this method is that everybody will have to shut down Office if you want to update the OTM file on the server (and if you do work in an office where everyone uses Outlook, you do know that it is impossible to get everyone to shut it down at the same time, except if you code a macro to do so eventually). To prevent both those problems, I could setup a batch file to copy the server OTM file clientside everytime there is a new version (just have to check the NTFS last-modify attribute). This way, Outlook will boot with a local file, the batch file take 2-3 seconds to copy the file if needed (or will launch Outlook instantaneously) and there will be no problem updating the OTM file on the server. Users will have to start Outlook with the batch file (or with the slightly different outlook.exe path with the altvba parameter, so either way they need a different shortcut/file to start off the first time). One other advantage of the altvba is that it's still easy for the user to run Outlook without it (to see if the VBA is problematic or not in case Outlook is sluggish) and the file will remain unchanged after a Outlook reinitialization.
Others solutions include a COM complement that can be developed in a lot on languages including VB6 (no conversion needed from VBA). There is also a bunch of tools included into Microsoft Office XP Developer that could help getting the job done (not free however, especially if you need the most up-to-date version).
I altered a stored procedure and unknowingly overwrote some changes that were made to it by another developer. Is there a way to undo the changes and get the old script back?
Unfortunately I do not have a backup of that database, so that option is ruled out.
The answer is YES, you can get it back, but it's not easy. All databases log every change made to it. You need to:
Shutdown the server (or at least put it into read-only mode)
Take a full back up of the server
Get a copy of all the db log files going back to before when the accident happened
Restore the back up onto another server
Using db admin tools, roll back through the log files until you "undo" the accident
Examine the restored code in the stored proc and code it back into your current version
And most importantly: GET YOUR STORED PROCEDURE CODE UNDER SOURCE CONTROL
Many people don't grok this concept: You can only make changes to a database; you can't roll back the stored proc version like you can with application code by replacing files with their previous versions. To "roll back", you must make more changes that drop/define your stored proc.
Note to nitpickers: By "roll back" I do not mean "transaction roll back". I mean you've made your changes and decide once the server is back up that the change is no good.
"Is there a way to undo the changes and get the old script back?"
Short answer: Nope.
:-(
In addition to the sound advice to either use a backup or recover from source control (and if you're doing neither of those things, you need to start), you could also consider getting SSMS Tools Pack from #MladenPrajdic. His Management Studio add-in allows you to keep a running history of all the queries you've worked on or executed, so it is very easy to go back in time and see previous versions. While that doesn't help you if someone else worked on the last known good version, if your entire team is using it, anyone can go back and see any version that was executed. You can dictate where it is saved (to your own file system, a network share, or a database), and fine-tune how often auto-save kicks in. Really priceless functionality, especially if you're lazy about backups and/or source control (though again, I stress, you should be doing these things before you touch your production server again).
You could look through the cached execution plans and try to find the one where your colleague made his changes and run the relevant parts again.
EDIT
Although Bohemian looks to have a good answer if you've got the changes in the TL, this is what I'm talking about. Review the SQL text for the plan.
SELECT cached.*,
sqltext.*
FROM sys.dm_exec_cached_plans cached
CROSS APPLY sys.dm_exec_sql_text (cached.plan_handle) AS sqltext
But as squillman points out, there is no execution plan for DDL.
You won't be able to get it back from the database side of things. Your options at this point are pretty much limited to 1) recover from backup, 2) go to source control or 3) hope that someone else has a copy still up in an editor somewhere or saved to a file.
If neither of these are an option for you, then here's the obligatory "you should take regular backups and use source control"....
I'm way late to the game on this but I did this same thing this morning and found I had forgot to save my script at some point in the past and needed to recover it. (It will be in source control after I get done fixing this!!!)
Some people mentioned restoring from a backup but no one really mentioned how easy this is if you have a back up. Moreover, you aren't locked into rolling back the production database. I think this is key and assuming you have a back up I would say this is a much better alternative to what has been voted up to the best answer.
All you have to do is take your back up and restore it to a new database. Pull out the sp you are looking for and voila, you've recovered the missing code.
Don't forget to drop the newly created database after you've recovered the missing file.
I had the same problem, and I don't have the confidence to go restoring from log files to another server. I was pretty distraught until I realised the solution was very simple...
Press Ctrl-Z over and over until I had undone my changes and the run the ALTER PROCEDURE again.
Admittedly I was pretty lucky that I still had it there to revert to but it really is the easiest fix. Probably a bit late now though.
If you have scripted the stored procedure out from management studio object explorer this will work.
Before expand and collapse the object explorer just scroll and point to the stored procedure you have opened. Script the stored procedure as create or alter to then you can get the previous version of the proc since the object explorer doesn't refreshed yet. This is always my life saver.