You really only need to check @@FETCH_STATUS = 0, that indicates that a row was successfully fetched.
I would say this actually depends on the type of cursor you open. There are 3 possible statuses in a fetch for a reason. So if you only check for 0 with certain cursor types you will possibly miss rows after a -2 status is returned by quitting before trying fetches on rows that are after the row which returned the -2 status. I believe static cursors would probably be fine to check only 0. But dynamic cursors will require you to check the possibility of a -2 @@FETCH_STATUS.
Note that Etienne_Lemire states there was -2 status.:
I did some debug of the script with the cursor, sometime it ends before the end when the "fetch next" returns some blanks instead of the DB name, with the fetch_status = -2
I tried what Adam told me and it works much better now. Now, if a fetch returns -2, the cursor moves to the next db, there will be only one db backup missing instead of all the remaining ones.
It looks like the "MASTER..Sysdatabases" table is altered often so maybe I will try to use the static cursor and I guess it will resolve the problem.
Thank you Adam!
Viewing 2 posts - 31 through 31 (of 31 total)