I’m evaluating TDM with both 3.4 and 3.5 beta
I’ve reverse engineered a PostgreSQL 8.3 database, succesfully, and I’ve tested alter script generation after adding a table, 2 referential constraint, 2 sequences, a trigger and a function used for trigger. The model itself is around 50 tables just to give an idea.
First comparisons step goes ok, very quick, and gives me correct informations about differences. Very nice. But when I try to generate alter script, memory and CPU usage start to grow (from 44.000 to around 155.000), it slow down, then application sometimes freeze, sometimes gives an access violation…
I’ve tried with a simple change (add one column) but no luck same effect… I’ve then tried to convert the videorental example to postgres and add one column… and that time it gave me the final result correctly… So seems somehow related with model size.
Same result with both 3.4 and 3.5 beta…
If can be of help, if you provide me an email address I can send you the two models, before and after changes…
Finally I’m testing on a xp sp3 virtual machine with 1024mb ram running on VmWare Player 3.0
We checked out the problem in current commercial and Beta versions. Unfortunately, we failed to simulate the problem. The process of alter script generation took from five to seven minutes, so, quite long. We will work on optimization of this process.
Nevertheless, in all testing cases the alter script was generated for your model successfully. No AV error occurred.
We would like to ask you for the following:
Please try to generate the alter script again. On page Settings in the Sync&Convert Wizard select the Log Progress to File checkbox.
(Note: To define a default path for the log file, select Settings | Options | Paths | General tab | Sync and Convert Log Path.)
If the error occurs, please send us the complete log output of the process. (On the AV error there is also Copy to Clipboard checkbox, so you can select it and send it to us too.)
The address is: modeling@quest.com.
I’ve sent to the address what I have: the log and an image of access violation. Sadly I don’t have any copy to clipboard checkbox, as you will see in image…
Imho if does work for you is related to the fact that I have the feeling that has something to do with resource allocation (and the fact that it takes so much to generate a small script seems confirming that), so maybe my poor VM with only 1gb of RAM falls down sooner than a more powerful dev machine.
In fact trying modifying a little bit Videorental I’m able to obtain the alter script with no issues. Maybe I’ll try to allocate more memory to VM to see if something changes, or I’ll send you some bigger model to check…
I’ve tried doubling the RAM available to the VM where TDM is running… still no luck in generation, always the same error, but the log is bigger… I think it’s really matter of computer resources available… I’ve sent the new log file to the same email address
Thanks
Thanks very much for all the information you sent us.
Unfortunately, we keep failing to simulate the problem. Our developers will need much more time to inspect it. So, I have created a CR for them. CR # 69 058.
Further tested on virtual Vista 32-bit, 512 MB, Intel Core 2, 2,4 GHz - full TDM and TDM Beta.
Alter script was generated in 3 minutes without any problems.
While I am a HUGE fan of virtual machines (I use VMware Workstation to run all my Windows environments), we have seen problems with various products and the memory management of Windows when running as a VM. For example Windows 2000 VM running TOAD for Oracle cannot scroll data grids properly due to memory goof between VM and Windows client OS. I bring this up because it sounds like you are running under a VM - so do you get the same problem if you run native. I suspect that you’re running into a similar memory issue - and in which case you’ll need to log a bug with your VM vendor.
I was finally able to generate the script installing and running TDM outside VM, in the “main” computer. It took some time, for such a simple script, but it worked.
Now I’ll try to reverse engineering a much more complicated database, try to do some changes and extract script from there, to better understand if I have to blame the software for being too much resource-intensive in this specific task, or if it is caused by the VM memory management itself, as the other poster says… Could be an interesting theory, but you said that you were able to achieve good results with a “minimal” VM with a “slow dog” OS like Vista… so I’m really confused…???
Anyway, if my tests with the bigger model will be OK, for me, for now, I can consider the incident somehow “resolved”…
Ok, I’ve found the time to test with a bigger model making a significative amount of changes. Launched outside VM worked well, altough it took avg 10 mins to generate alter script…
So for now is closed, but I think some more optimization on this process shoud be applied…