Q: Does Data2Data™ support copying data structures between DBMS types in addition to data? Can I actually copy an entire database schema from a MySql database to an Oracle database for example, including its data?
A: Yes you can. You can copy structures and data to and from Sql Server, Oracle, and MySql databases. You can also copy structures and data from any other OleDb data source (Access, Excel, etc), as long as you can enter a valid connection string for that data source.

Q: Which DBMS types are supported by Data2Data™?
A: Currently the program supports Sql Server, Oracle, and MySql as both source and destination databases. It also supports the use of "generic" OleDb as a source. In other words, if you are looking to source data from a provider other than the three previously mentioned, you may be able to do so by using the OleDb option and manually entering an appropriate connection string. To find out whether a particular OleDb data source will work as a Data2Data™ source, download the free Evaluation Edition and try it out. And please let us know of your successes (and failures) in that regard.

Q: Are there any limitations to the Evaluation Edition?
A: There are no limitations to the Evaluation Edition, other than the fact that it will only allow you to export three tables (and their associated keys and indexes) at one time. The Professional Edition will let you export an entire schema at once.

Q: My source database has 20 tables. I chose to export only 10 of them, along with all of the Primary Keys, Foreign Keys, and Indexes for those 10. Some of the Foreign Keys did not get exported. How come?
A: In order for a Foreign Key to be exported, you must export not only its containing table, but also its referenced table. In other words, let's say you have a Department table and an Employee table, and the Employee table contains a Foreign Key that references the Department table. If you only choose to export the Employee table and not the Department table, Data2Data™ will NOT export the Foreign Key that references the Department table (even though you may have checked that Foreign Key's checkbox) because it would end up being invalid in your new database since its referenced table (Department) does not exist in that new database (because you didn't choose to export it).

Q: In the Source/Destination Window, why does the login screen look different depending on the DBMS I choose as my source and/or destination?
A: Each DBMS type is different. For example, what Sql Server calls "database", is analagous to "schema" in Oracle. Aside from using different terminology to describe similar concepts on occasion, the DBMS types also differ in that many have differing login requirements. For example, Sql Server allows a user to login using Sql Server credentials or their Windows credentials. Other DBMS types don't do that. We've tried to tailor each DBMS type's login screen as specifically as we could to its requirements. In addition, we've provided the ability to manually enter the entire connection string if you want to specify connection options that we didn't specifically provide for.

Q: Can any OleDb data source be used as the Source DBMS in Data2Data™?
A: We've provided OleDb as one of the Source DBMS types in Data2Data™. Whether or not a particular OleDb data source will work with Data2Data™ depends on whether the developer of the data provider complies with recognized practices for data provider development. A minimum requirement is that they render the data presentable as tables and rowsets. If that's the case, Data2Data™ should be able to pull out tables and export them to whichever supported destination DBMS you choose. In addition to Microsoft Access, an example of a "non-database" OleDb provider that works with Data2Data™ is Microsoft Excel.

Q: Why must I manually enter a connection string when using the OleDb source option?
A: Since there are many different OleDb-compliant .NET providers out there, it would be impossible to know the login requirements and details for each one. The OleDb provider developer should be able to tell you how to construct a connection string for that provider.

Q: Are you planning on supporting any other DBMS types in the future?
A: Yes. We are currently considering Sybase, and we are open to others as well. Feel free to make suggestions in that regard.