So, I use A5�s Duplicate Tables/Sets utility to copy table /set structures to another directory. Peachy. The duplicated files all show up in the new directory and can get added to the database running from that directory.
Not so peachy. A5 creates duplicate references in the table/set listing of original database for each table/set duplicated. So now in addition to the original tables/sets listed in the original database there are now new references pertaining to the duplicates that exist in the new directory. Why? The duplication path is totally different than the origin path.
But even more not so peachy is that A5 allows tables/sets being duplicated to be use the same names as the originals which � you guessed it � generates a second identical looking reference in the original database. Ouch!
E.G. duplicate C:\test\Anytable to C:\new test\Anytable. The original database running out of C:\test now shows two Anytable references in its table listing, one pointing to C:\test and one pointing to C:\new test. It is not apparent unless the properties of each table reference are individually checked that these two identical looking table references actually do each point to different locations.
Talk about confusion. Which one is the one I want to keep and/or use in the original database ? Ok, so one can specifically check the table/set properties to ascertain. But one better still be careful not to delete or rename the wrong one. Of course unless one of the duplicates (hopefully the right one) gets deleted or renamed have fun trying to deduce which of the duplicates to use in a set design.
This behavior doesn�t make a lot a sense to me. 1) Why should A5 create a new references for duplicated tables/sets in the original database at all if the destination of the duplicates is explicitly directed to a different directory than the originals? 2) If A5 is going to insert these references to the duplicated tables/sets back into the original database, regardless of the duplication destination, then why would it not trap the use of identical names? This situation has created more than minor frustration in learning/testing A5 for me. If it were just learning curve frustration � but this augurs badly for actual application development wherein the deletion or use of wrong duplicated table/set references seems so easily possible. Perhaps I am not understanding something here with the A5 duplication utility functioning , but as it sits this seems to me to be a bad tool design.
Not so peachy. A5 creates duplicate references in the table/set listing of original database for each table/set duplicated. So now in addition to the original tables/sets listed in the original database there are now new references pertaining to the duplicates that exist in the new directory. Why? The duplication path is totally different than the origin path.
But even more not so peachy is that A5 allows tables/sets being duplicated to be use the same names as the originals which � you guessed it � generates a second identical looking reference in the original database. Ouch!
E.G. duplicate C:\test\Anytable to C:\new test\Anytable. The original database running out of C:\test now shows two Anytable references in its table listing, one pointing to C:\test and one pointing to C:\new test. It is not apparent unless the properties of each table reference are individually checked that these two identical looking table references actually do each point to different locations.
Talk about confusion. Which one is the one I want to keep and/or use in the original database ? Ok, so one can specifically check the table/set properties to ascertain. But one better still be careful not to delete or rename the wrong one. Of course unless one of the duplicates (hopefully the right one) gets deleted or renamed have fun trying to deduce which of the duplicates to use in a set design.
This behavior doesn�t make a lot a sense to me. 1) Why should A5 create a new references for duplicated tables/sets in the original database at all if the destination of the duplicates is explicitly directed to a different directory than the originals? 2) If A5 is going to insert these references to the duplicated tables/sets back into the original database, regardless of the duplication destination, then why would it not trap the use of identical names? This situation has created more than minor frustration in learning/testing A5 for me. If it were just learning curve frustration � but this augurs badly for actual application development wherein the deletion or use of wrong duplicated table/set references seems so easily possible. Perhaps I am not understanding something here with the A5 duplication utility functioning , but as it sits this seems to me to be a bad tool design.
Comment