0

I have WinForms application that uses ADO.NET to communicate with MySQL database. Some sql queries are 2000 lines long, some are generated dynamically. This application connects to existing database, and uses only some of it's tables.

It needs to be migrated to it's own server, so I need to know what columns in what tables does it use (so we don't need to clone entire database, but only needed portion of it). I don't really know how to do this, besides going though all queries manually and noting table and column names. Is there a better way to do it?

maxc137
  • 2,291
  • 3
  • 20
  • 32
  • maybe use profiler to monitor the query while you are using the application? BTW, why not migrate all the data? – urlreader Oct 14 '20 at 15:33
  • @urlreader Main database will continue be used, and new data from it will need to be continuously copied to this application's database. Main database cannot be used by this application anymore, because it migrated from MySQL to MSSQL. This application won't be migrated to MSSQL since a lot of queries will need to be modified of rewritten. – maxc137 Oct 14 '20 at 15:43
  • @urlreader Does mysql have a profiler like MSSQL? I remember, some time ago I tried to get it running, but with no luck. – maxc137 Oct 14 '20 at 15:45
  • https://stackoverflow.com/questions/20263/is-there-a-profiler-equivalent-for-mysql – urlreader Oct 14 '20 at 15:46
  • @urlreader Good to know, thank you. But I'll still need to go through all the queries and write out table and column names from them. And now I will be at risk that some queries weren't executed when I profiled the application. Seems like it will be better to go through the queries in source code that use profiler – maxc137 Oct 14 '20 at 15:49
  • 2
    This sounds like a terrible idea. Why not just clone the entire database? The chances of successfully identifying *all* database objects (functions? triggers?) by just reading the code is near zero, and by profiling the code is still not 100%, as functionality can be missed (unless extensive unit tests exist that test *all* functionality). I've seen similar migrations, and they are usually a disaster unless the approach is reversed - clone the entire database, and then clean it up over time by renaming objects suspected to be obsolete, and eventually removing confirmed obsolete objects. – CoolBots Oct 14 '20 at 16:02

0 Answers0