May 1, 2018 at 1:30 am
When our front end application do any data manipulation like insert, delete or update , is there any way to find which table is affected
. i know this sounds quite amateur, we have an application and its connecting to our database of more than 500 tables and now i want to bulk insert records to some particular table in the database.But I do have hard time finding the columns and tables which is corresponding to the front end side of the application?
How to find tables which are manipulated from the front end , is there any way to find it ?
May 1, 2018 at 2:17 am
Out of the box, no, not really. You might be able to find something in the default trace, however, the only way to guarantee this is to set something out yourself; considering you asking how to find it, that implies you haven't set up anything to do so.
The fact that you're saying from the Front End, as well, implies that you're saying you only want to know about data that is changed via the application, not if someone opens up SSMS and runs an UDPATE statement, correct? You'll need to therefore ensure that your application is passing it's name in it's connection string, so that you can identify it, and then you'll probably want to make use of Extended Events. I can't give more precise information, as I don't have any further information to give a more detailed answer on.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
May 1, 2018 at 2:51 am
Further on Tom's fine reply, it looks like you have a greater problem on your hands as it appears that there is a "black box" logic embedded in the front end. Ideally, one maps that logic to both the front end processes and the underlying data model. Without such mapping, chances are that you will get the bulk loading wrong. Even better would be moving all the logic into objects and procedures in the database.
😎
One way of approaching this is to create a scripts that takes max IDs and temporal column values from all the tables in the database, run the script then do something via the front end and then run the script again. This is dependent on the structure of the database and not fully reliable, but at least it can give some ideas on what is happening.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply