Is there any data export framework in .net or something.I have need to device a tool kit to export legacy and data from older/legacy application to the new application under development,there are around three similar systems.To give you an idea the three have employee table.Is there any framework or dsl tool for this? Or I have to come up with all the code? How do you guys do it when you have customers whom you want to migrate to the new product ?
Hi,
if the schemas of your database stay the same, so making more of an copy of the legacy system, you can make use of Visual Studio which has a Data menu item under which you can start a Schema comparison or Data comparison to transfer them from one server to another.
Grz, Kris.
Having migrated from NN tools to our application, I can tell you that there’s no “easy way” to do it. Each piece of software follows its own internal database structure and it will never be the same you followed when designing your own.
With that in mind, the most complicated task is usually divided into two parts:
1) Determine what and how is the data stored in the legacy system. You know the table PAXNOST means Patient_Note_Statistic or things like that… Once you have an idea where the data is (in one or more tables)…
2) Export it and sanitize it: More often than not, using an import wizard in SQL server will result in data not being imported due to “errors”. Data truncations, Null values where there shouldn’t be allowed, dates with incorrect format (01/02/1009 for example) and things like that. These kind of problems vary from migration to migration but it all depends upon the constraints the older system enforced (or not!).
If you manage to do all the above, you can import into your DB of choice (SQL server I assume) and then, when all the data is in the same DB and with the minimum number of “strange things”, you can proceed to use T-SQL (or any other more automated process, I use T-SQL Scripts that I have saved and can re-use if I have to), to move data from OldTables -> new tables.
Always save every script you execute. Assume you might have to re-execute it all.
Always back up your db after “important steps” so you can restore -> fix -> re-do if you have to.
And remember that you will almost always have to tweak certain things by hand (I.e.: update xxx set yyy = ‘’ where zzz = null; and things like that to make sure constraints are ok. Again, this all depends upon the quality of the source data. Always assume the worst.
Have a good Text Editor in which you can perform fast searches / regex, be cautious with line endings and field separators if you use a mix of Windows / Unix (in case you use ASCII files, which I often do); also using MS ACCESS or MS EXCEL for quick table import/sanitize is never bad if you have those tools (Excel can’t have more than 65535 lines per sheet, remember that, use Access).
Data Transfer Objects (DTO) is nice, but depending upon the task, sometimes it turns out to be a PITA.
Good Luck.