July 28, 2016 at 8:12 am
Hello. Hope I am posting in the correct forum. I have some database experience though I am somewhat new to SQL Server so I have what I think is a general question (I hope). It is as follows:
"How to trace data movement through backend SQL stored procedures and functions?"
In a nutshell, I just need some direction on this. Are there canned stored procs and or functions that can do this or does this have to be done via custom stored procs/functions? Any insight or just a general outline would on how to do this would be most helpful.
Thanks for any help you can provide.
Joe
July 28, 2016 at 8:21 am
Can you provide some more descriptive examples of what you are looking for? I am at a loss given your initial posting.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
July 28, 2016 at 8:44 am
Thanks for the response. Say I have application A. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs etc., in the backend.
However, for UI (logon, reporting etc), I am using say Access (or something else) for the frontend.
The goal is to have the database reside on a server and let clients connect with an instance of Access running locally on their machine. Using SQL Server how would I trace data movement via stored procs/functions if possible. Does this make sense? Excuse the ambiguity as I am new to this.
July 28, 2016 at 9:03 am
jmlc1 (7/28/2016)
Thanks for the response. Say I have application A. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs etc., in the backend.However, for UI (logon, reporting etc), I am using say Access (or something else) for the frontend.
The goal is to have the database reside on a server and let clients connect with an instance of Access running locally on their machine. Using SQL Server how would I trace data movement via stored procs/functions if possible. Does this make sense? Excuse the ambiguity as I am new to this.
1) Access would simply be doing pass-through sproc calls to make stuff happen.
2) Your idea of tracing "data movement" is flawed I think. You should know what happens to your data because you know what all sproc calls do with anything passed into them (both into and out of the database).
3) You have visibility into executions that happen using Profiler, which is a tool that comes with SQL Server installation (you can do just tools only on your dev box if you want). You can also see executions via Extended Events, but as a newbie I would definitely recommend using Profiler.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
July 28, 2016 at 9:38 am
further to the good ideas by Kevin....I am wondering if your requirement of "data movement" translates to audit tables that record changes made to the SQL data, by whom and when?
just a thought.
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply