Options
Another request for setting Column A based on Column B
DavidGInNewWest
Posts: 2
I am also in the boat where, in order to be able to generate data, I need to inspect various columns in a row before setting another column.
Our database has a table that stores patient problems. A problem may be based on a predefined problem, or may be ad-hoc. There is a trigger that says, "If the ad-hoc column if set, the pre-defined column cannot be, and vica versa".
I also see that the data generation for an individual column is isolated - the tool generates Column 1, then Column 2, then Column 3 - it's apparent in the interface and capabilities of the software. Data Generator 2 is just not designed to work row-by-row; it works column-by-column.
It would be nice if each column-function (the code that returned a row for the column) operated on a row-by-row basis, rather than in a generate-all-column-data-at-once fashion.
I understand this is not possible unless I go through the trouble of duct-taping IronRuby onto the outside (and then learning Ruby). What about IronPython?
I guess I can sort of work around this by disabling the trigger on the table by adding before-and-after scripts to the project, but that won't work in all cases, and could lead to invalid results when I test.
Finally, the UI is kind of screwed up for Windows 7 - lots of labels are squished together, UI elements overlap, etc.
The tool is great for generating a users table, but it breaks down pretty quickly once the rules get a bit more complicated....
Our database has a table that stores patient problems. A problem may be based on a predefined problem, or may be ad-hoc. There is a trigger that says, "If the ad-hoc column if set, the pre-defined column cannot be, and vica versa".
I also see that the data generation for an individual column is isolated - the tool generates Column 1, then Column 2, then Column 3 - it's apparent in the interface and capabilities of the software. Data Generator 2 is just not designed to work row-by-row; it works column-by-column.
It would be nice if each column-function (the code that returned a row for the column) operated on a row-by-row basis, rather than in a generate-all-column-data-at-once fashion.
I understand this is not possible unless I go through the trouble of duct-taping IronRuby onto the outside (and then learning Ruby). What about IronPython?
I guess I can sort of work around this by disabling the trigger on the table by adding before-and-after scripts to the project, but that won't work in all cases, and could lead to invalid results when I test.
Finally, the UI is kind of screwed up for Windows 7 - lots of labels are squished together, UI elements overlap, etc.
The tool is great for generating a users table, but it breaks down pretty quickly once the rules get a bit more complicated....
Comments
As far as the display issue I am running windows 7 and do not experience the issue you are describing. I believe it likely to be a diplay setting on your machine causing the issue either a resolution setting or DPI.
Product Support
Red Gate Software