Hi Cheis;

  For the ShareData() to work, all the DWO's must have the same number of columns, same data types, and the columns in the same order. The only way the "primary" DW can ShareData() to secondary DWO's is to use PB's Dynamic DW feature where you pass the SQL statement to build the DW Source "on the fly". However, this does nothing to control the formatting of the secondary DWO's (without a "ton" of coding).

     Offhand, I cannot think of a viable way to dynamically ShareData() while changing columns "on the fly". It's a "Kool" idea though. No problem to do this in hidden DataStore's but not (IMHO) for visible DWO's in DW Controls where control of the GUI is also required.

Regards ... Chris

We have a setup window with 8 tabs of shared data. Although having to hit each DW when we add a field to any of them is a pain, it's never been trouble enough (for 20+ years) that I've actually coded up a automated solution for it.

You would need to export each datawindow object to string, pull the table object from the master DW, and replace it in each shared object, then save the object back out to the pbl. This will give you the select & column definitions, but not add the GUI field to the datawindow itself.

It's pretty easy to modify the master DW in GUI mode, add the column to the select, delete the GUI field if you're not using it on that DW, and save the DW. Then open the master datawindow in source mode, copy the table object to clipboard, then open each shared object in source mode and replace the table object. Since you don't need the GUI field in all versions, you'll only need to edit source once for each DW. Once you've pasted in the new table object into all the DW's, you can then open whichever DW object needs the new field and place it where you need it. This should take all of about 10 minutes once you've done it a couple times.

One word of warning though: If any of your shared DW's have columns with dropdown lists, radio buttons, checkboxes, DDLBs, or anything that causes "values=" at the end of the table/column definition, this will overwrite them, so make sure you've gone through and compared each DW to master to see if there are any and put them on the master DW before pasting over anything. So far I haven't had anything remove the values= data unless you place the GUI field and set it's edit style (then it will wipe it, and you can either replace it from a shared DW in edit source mode, or manually put them back in through the PB GUI on the DW Edit tab).

Hope this helps.

(and before you begin - BACKUP your PBLS!!!)

Thanks guys for the input. I was hoping there might be some easy trick out there to accomplish this. Manual maintenance it is!

Hi John - I agree its not a big deal to do it but the problem comes in when you have multiple developers hitting this window. They forget to modify all the other DW's so then our QA department creates a bug report, writes up the document, etc - wasted overhead for something that is so simple to fix. Plus - I always like automating mundane tasks!

Chris Craft

One other note - I have never used Query Objects before but I would have thought if you modified the query there would be a way to refresh all the other DW's that used that object for its data source but I do not see anything like that. If that's the case whats the point of using a query object?

Chris Craft