Problems backuping Views with TMyDump
Posted: Thu 08 Nov 2018 12:28
Hi,
Several MyDAC users before me have reported a problem of using TMyDump when backuping a database with a large number of Views with inter-dependencies (joins among Views).
As I understand, TMyDump.BackupToFile writes all views to the dump-script file in alphabetical order. However, as TMyDump.RestoreFromFile only executes the dump script, it also follows the same alphabetical order when recreating the views. However, the alphabetical most likely does not capture the joins (inter-dependencies) among Views. Thus, TMyDump.RestoreFromFile tries to create one View that depends on the pre-existence of another View, which has not been created yet because it is further ahead in the alphabetical order.
Surprisingly, dbForge Studio does not have this problem! The algorithm is smart enough to figure out all the joins between views, and write them in the proper order.
How come (1) a bug reported over 10 years ago has not been fixed yet, when (2) DevArt has already figure out the solution but failed to implement it one of its products.
Yes, I know that I can use TableNames for set the order of Tables and Views. However, I should not be hard-coding the name of the Views, because the number and name of Views will certainly change over time.
I would appreciate a prompt solution.
Several MyDAC users before me have reported a problem of using TMyDump when backuping a database with a large number of Views with inter-dependencies (joins among Views).
As I understand, TMyDump.BackupToFile writes all views to the dump-script file in alphabetical order. However, as TMyDump.RestoreFromFile only executes the dump script, it also follows the same alphabetical order when recreating the views. However, the alphabetical most likely does not capture the joins (inter-dependencies) among Views. Thus, TMyDump.RestoreFromFile tries to create one View that depends on the pre-existence of another View, which has not been created yet because it is further ahead in the alphabetical order.
Surprisingly, dbForge Studio does not have this problem! The algorithm is smart enough to figure out all the joins between views, and write them in the proper order.
How come (1) a bug reported over 10 years ago has not been fixed yet, when (2) DevArt has already figure out the solution but failed to implement it one of its products.
Yes, I know that I can use TableNames for set the order of Tables and Views. However, I should not be hard-coding the name of the Views, because the number and name of Views will certainly change over time.
I would appreciate a prompt solution.