Save the generate data options

I am attempting to populate tables in my database using the generate data tool.

I would like to save all the settings in order to re-run the data generation job tomorrow.

As with any screen/wizard/feature in toad look to bottom left corner of the window for a camera icon - meaning to capture your settings as an action/application. Then read the online help and many blogs on using the toad app designer - which is exactly what you are looking for. It allows one to record what they’ve done for later replay, offers ability to run that via command line, and to be able to schedule it for execution …

This is great , I have used this function to save, export , import an XML file that contains the instructions to load a set of tables using Test Data Generator, however how can you make a change to a table and then refresh the schem in the TDG somehow, and actually re-use all the work completed to this point. We are doing agile data modeling, and every week there is a potential change to some table, so if I create all the work to build a template with many tables to have data generated for, I don’t want to have to start all over again to re-create the template simply since one of the tables has a new or modified column ( changes are add col, delete col, change data type, change nullity).

Can the save / refresh within TDG do that? Please let me know if someone has an answer, I even had the tolad team demo this to us, and there was not deifinitive answer, except this reply idea, howver that does not answer my question - thanks!

Hey Carol,

There currently isn’t a way for Data Generation to automatically sync itself back up to the database after a schema has been changed. The exported object hierarchy currently relies on the action’s schema information matching the database schema.

This is not a bad idea, though. As your situation implies, I’m sure this issue happens to more than just your company. We’d have to put in some logic, not only to provide notification that the schema has been changed, but to allow you to identify exactly what has been changed. if you’re working with a few tables, each with a few dozen columns, finding the few columns that may have changed in that list since you last worked on it would be a bit tedious. :wink:

It may not be something I’ll be able to get in for this release, but I’ll definitely see what I can do for the next beta cycle.

-John