I'm using the BACKUP DATABASE SQL to backup the tables. It runs fine,
but the database.Execute() function returns 0 rows affected. What is
the proper way to determine if the backup was all good or not. I'd hate
to find it was reporting an error and I was missing it. I can of course
check that there is a file created, but what if it was only half
complete?

--

Matthew Jones

Matthew


Where I've used it I've just assumed that if it hasn't crashed its worked. I know you get a message in EDBManager so you could have a look in there and see what Tim does.

As always with a backup the only real test is RESTORE

Roy Lambert

Roy Lambert wrote:
> As always with a backup the only real test is RESTORE


Hmm, restore, good point. I should practice that...

--

Matthew Jones

On 5/26/2014 5:25 AM, Matthew Jones wrote:
> I'm using the BACKUP DATABASE SQL to backup the tables. It runs fine,
> but the database.Execute() function returns 0 rows affected. What is
> the proper way to determine if the backup was all good or not. I'd hate
> to find it was reporting an error and I was missing it. I can of course
> check that there is a file created, but what if it was only half
> complete?
>

There should be OnProgress and OnStatusMessage messages generated while
backup runs as well as exception thrown if fails (i believe).

Also once it's done you can use the "set backup store" and query the
"Backups" table in the config DB.

Of course test restore is the only real test.

Raul

Raul

>Of course test restore is the only real test.

That's a lesson I learned a short while ago (say 20 years) just after I started out in recruitment. I built my own system (AP/DOS) and decided I wanted to make sure I was safe. Bought a nice tape drive, backed up and verified every night using grandfather/father/son approach. First time I needed to restore none of the tapes worked.

Roy