1. 

   Ken, Member

   The way myDBR handles saving (or not) procedures with errors basically guarantees that at some point, you WILL lose at stored procedure. One of the most insidious ways I discovered is by being in the middle of an edit of a stored procedure and then having some sort of interruption take you away from the edit. If you are gone long enough for myDBR's auto timeout to kick in and log you out, you will lose both your edits and your stored procedure.

   I assume the same could happen if you start edits and lose your internet connection.

   Consider offering some sort of previous version saving scheme, or a simple auto-save feature with a user defined saving time.

   Better yet... just allow us to save a stored procedure that has errors so that if we get too fast on hitting Execute and then tabbing away, we don't lose our edits.
2. 

   myDBR Team, Key Master

   When a procedure is saved to the database, it first needs to be dropped and then re-created. If there is an error in the code, depending on the error and the database used, databases generally do not allow saving errornous procedures to the database.

   To avoid losing reports, myDBR saves history of your command execution and saved object (History-button). Also, original version of the report code is kept behind the Original-tab. Original-tab is kept as long as you keep the window open and versions behind history button are saved as long as the session lasts (you can define the session length in settings).

   --
   myDBR Team

Reply

You must log in to post.