Environment refresh vs creating Data using scripting

Hello
I am not a big fan of Environment refreshes(lot of data currently about 200GB as we have to yet purged the data) , then data security issue and lists goes on and on.
I was wondering, if any one has come up with a way to create data using some sort of scripting tools. I would like to hear about it. I would appreciate if you could share your experince about it.

200 GB is not a lot of data.

What type of scripting tool are you imagining here? The easiest thing to do here is copy the entire thing and then run JDE standard purges to remove seveal years of data.

Seeing how most hardware vendors have moved to 600 GB drives as a basic standard kinda puts things in perspective.

Colin

Nick,

You might look at iRefresh, from The iConsortium. I know there were discussions about how it could be used to 'dummy' data, into non-production environments - but, I don't know if that consideration ever fully played into its development.

http://www.theiconsortium.com/content/view/194/228/

Feel free to contact me (pm or email) - if you have any problems contacting them.

(db)

Ok - you have a couple of options.

The best way is to use SQL to create a subset of your production data, then "garble" specific values so that your testers/developers cannot view actual data. This "garbling" can be done through some sort of randomization.

The second method is to create a golden data set using a completely different set of data. The risk here, of course, is that you are likely to end up with data that does not correctly test your actual setup correctly.

Beyond that, there are several "data load" screens, depending on your functionality, that could conceivably take large quantities of data and enter it directly into JDE using Z file processes or something similar.

One thing I often create for customers is a "golden dataset" of data at a specific int in time. That golden dataset is a known quantity and is set, for example, as of a date of 15th April 2005. when ube's and other processes run, there is a known set of results, so the data set can be refreshed each time prior to the test runs. This is known as "regression" testing - testing known functionality for known results when code might have been modified.

I can provide more information if required - I have several white papers on my website that discuss these in depth.