Using Toolkit for Application Backup & Restore

pearsons_11114

I would like to use the toolkit to enable a backup/restore capability for my application. It seems pretty straightforward just to follow the example for SQL Packager, just doing the data portion. However, what's not immediately clear is where to stop short of creating an executable package.

I'd like the backup to save the results of the data compare at some intermediate point. I'm just getting familiar with the API, so it's not clear to me yet where that would happen in the process. The restore would read this back in and execute the script. I'm sure I can eventually figure out the best way to do it, but I'm wondering if anyone else has done something like this.

pearsons_11114

I guess the answer would be no. It appears that packager portion of the API is pretty severely crippled. There's no access to the methods that break up the scripts into compressed batches, so you'd have to roll your own and recreate what they've done. Likewise there isn't anyway to run the batches except by recreating what they've done in the project that gets exported from Packager.

That's a bummer because this is one of the main reasons I bought the toolkit. I wonder why they would set it up this way? I can't think of a use for the packager portion of the API as it stands. The only thing it can do is create an executable. I guess that would be ok if not ideal, but you don't have any control over available options. In my case I want to predefine parameters such as which database will be used. I don't want users to have the option of creating a new database. Anyone actually using this part of the API for anything?

pearsons_11114

Ok, I see I missed something. Apparently you can specify to output a project from the constructor. So, that would get you the compressed batches, albeit with a bunch of other stuff you don't need. Maybe there is a way to ignore the template aspect of things. I guess you could just delete everything except the batches afterward. Kinda messy.

So, the remaining effort would be to APIize the template code.

pearsons_11114

Ok, I see from another post that I'm barking up the wrong tree. The way to do this is to forget about the Packager API entirely and intervene at the ExecutionBlock. Serialize to backup and unserialize to restore. It's not clear from the doc. whether this is possible, but it appears to be set up that way. Pass the ExecutionBlock to (strangely) a BlockExecutor.

Anyone wants to reach in and put an end to this flail-ex, I'm all ears. ;-)

Brian Donahue

Packager is pretty limited in that respect. Using the API to create a package has you writing more code to compare databases and produce scripts than to create a package; the Packager code pretty much limited to setting the settings and calling Packager.Package().

The best solution I can think of to get at the compressed batches is to let Packager compile an executable and then use reflection to get the resources out of the output file with some kind of resource reader.

Presumably you'd want to run the batches at some point, so then you're stuck figuring out how to use the zlib.dll to uncompress them again.

It's a sticky situation either way.

pearsons_11114

Thanks for the help. Executable is not really an option as a customer would certainly try to execute it sooner or later. Plus, given that the ExecutionBlock can't be recreated (see below), it's not really buying me anything. I think it's simpler for me to write out the scripts, rather than trying to dig it out of the executable (over my head a bit). In either case I have to adapt the template code for execution. (For compression, I have my own lib I can use).

It turns out that the ExecutionBlock can't be recreated. The constructor is private, and however it's done internally is not exported to the API. The thing that's strange is why the Packager authors did not opt for this approach. They certainly could have created methods to serialize and deserialize the ExecutionBlock. You end up with redundant code in the template for reading in and executing. Very odd.

Feedback here is that the API seems unnecessarily crippled, and a number of published methods are undocumented (e.g., AddBatch), so I'm not sure what they're doing in the API. Needs a little more time in the oven.

Brian Donahue

Because the Packager design leverages the existing SQLCompare and DataCompare Engines, it does have some limitations. Currently, these engines are being modified to provide more application-specific features. I could see the support for Packager improving in the future.

fordc03

Sounds cool...but...why would you want to do a backup/restore in that method?

Are you trying to accomplish some sort of "snapshot" method to do a hybrid sort of incremental backup?