I drag my .cls file to Intersystems studio, the old version code covered my latest version code, is there any way to get back my covered cls file ?
InterSystems Caché/IRIS stores most of the code right in the Database, and Database by default is journaled. So, you can revert your code by those journals. But unfortunately, it is not so easy to explain how to do it.
Related
For development within our Oracle 11g database we use Toad for Oracle and Git (in TeamCoding).
One of our development rules is to use the Toad Autoformatter to have a persistent "code appearance". Since we want to change this rule set (towards less line usage), every file would be entirely in the changelog when switching from old to new formatting, making it impossible to see the actual change diff.
Also db objects would only switch to new formatting when being changed.
Is there a way to apply the Toad Formatting rules to all objects (in the database via Toad or maybe in the Git directory)? Then we could make a minor Version which only switches all objects from old to new formatting. :)
Thanks in advance!
ps: manually doing this would be possible ofc, but could take some time since we have a lot of objects in the database :D
Facing the same problem, I could not find a complete massive way; the best thing I can do is:
go to Schema Browser
select all the objects
do "Create script"; in "Script options" panel you'll find the format option, so you can download formatted code.
compile all the objects to save formatted code on DB
In this way you neeed to navigate a bit through the browser, but I hope this can help anyway.
(tested on Toad 12.1.0.22)
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
Im finding myself using TextMate 2 more and more for development these days
One thing that is bugging me is that it does not seem to reload a file when it is changed externally.
This is a big problem since I use terminal to switch git branches a lot, and it often results in accidentally saving an older version over the new branch
Sadly the TM team seem to have disabled the Issue tracker on github, and documentation just seems scattered far and wide over the web in tiny scraps.
Any ideas?
Right now it reloads the file silently whenever the file on Disk is changed. There is currently no option for a prompt.
Regarding the closed issue tracker: As an alternative, you can always send a mail to the Textmate users list if you find a problem.
I just updated to TM 2. In the past, I have enjoyed using TM to view development.log as I am introducing new or modified code. TM 1 would ask me if I want to revert to what's on disk and of course I would respond with Yes. Then I could see any additions to the log file. Occasionally I would empty the log file with Cmd+A, Delete, Cmd+S. Macromates, please make TM 2 work like TM 1 reloading content.
I also could not find a solution to this problem which is still there, however it is possible to file an issue using this contact page: http://macromates.com/support
Additionally there are hidden setting which cannot be set from the GUI. Unfortunately they don't include and setting for automatic load from disk: https://github.com/textmate/textmate/wiki/Hidden-Settings
I highlighted a line of code I was going to delete after building and running the app. After I ran the app, the code was still highlighted so I pressed delete and my entire class was deleted... I am an idiot...
The file did not go to the trash so I thought xcode might store it somewhere, does anyone know if it is possible to retrieve this file?
you can easily revert if you are using version control. if you are not using it (yet), you should -- worse things happen.
if you don't use version control and you use xcode's snapshots... you could look there. you may also be able to find it using Time Machine.
but... add "learn version control" to your #1 thing to learn this week for development.
I used the Disk Drill to restore mistakenly deleted files.
check http://www.cleverfiles.com/
I'm using the Database project in visual studio 2010 to generate a script to deploy my database (and it's changes). This works great.
Is there a way to have Visual Studio database project generate a rollback script as well as the deployment script.
I'm not looking for rolling back the transaction while deploying; but say I deploy it and my stored procedure has an overlooked performance issue that comes up a week later that requires a rollback to the previous version of the database.
Is there a way to generate the rollback script at build/deploy time that will undo whatever changes the deployment script made.
EDIT: If we ignore that I'm using a database project: What is a good way to have an upgrade and downgrade path for a database generated?
This generation needs to be part of an automated build process.
To create a rollback script While doing a schema compare using VS2010, It is as simple as swapping the db names specified in the source and target.
This way VS2010 would create a rollback script which would have drop statements against your stored proc.
I've not seen anything like that.
I think you need to reconsider this approach, as you'd still need to fix the stored proc in your database project, otherwise you'd just be re-deploying the "bad" version the next time you deploy. (I'm sure you're already aware of that, but it doesn't help to point out the obvious sometimes!)
If you need to restore an old version of the sproc to the server in the mean time, I would have thought that the easiest thing to do would be to get the previous version from source control and manually deploy that.
You could create a backup of the database before the release and then just restore from the backup if things go wrong. Obviously you'd also loose any data changes (either made as part of the release or subsequently) since the backup was taken.
Another idea I had was to create a snapshot before the release. The operation to create a snapshot is very light weight. I'm not sure you'd want to keep the snapshot for a week, but if the release went wrong then I think it would be quicker to restore from a snapshot than from a full backup. I would be interested to hear any comments people have on this idea.