A couple of the most obvious reason for me would be, a database may not flush data to disk until a connection is closed, or a connection could be in the middle of a long running operation, possibbly in a transation or not, backing up the database when this long running operation is in the middle of doing what it needs to.... Your data if you restore it in the backed up state you'll have data corruption.

I might suggest there is a problem with GetWindowThreadProcessId, I do UI automation testing, i was looking a using GetWindowThreadProcessId a few weeks ago. Bottom line from what i found if you are on Win95, or NT 3.51, GetWindowThreadProcessId should work fine, on Vista I thought i remember seeing warning about it not working correctly. Alternatively, i might suggest 1.) Make sure you app is modal, that only one instance of it can be running. 2.) Get the process by GetProcessesByName() for your process, and then issue a kill on the process you find, well if it is still running. HTH, dan d;)

Something about this question just seems wrong to me. There should be one table in your database that contains all your "Customers" for example. Seems like a bad design to have "Customer_1_Jan_2009", and "Customers_2_Jan_2009", will you really want to query 'x' Customer tables for given date range as in the example provided? Alternatively, if you have for example a Customer table in your database, and each customer might need some additional data for each individual customer, i would highly suggest storeing the additional information within an xml column if possible. Or better yet figure out exactly what data you need to store, track, and maintain. You might have some specialized need to store data in this manor, but i simply can't think if a reason for it, seems like a bad design, and if you need to store daily inform for a given customer, then the date value should simply become a value withing the record.