Results 1 to 4 of 4
  1. #1
    Join Date
    Nov 2008

    Unanswered: Need to Analyze Tables and Joins

    I need to create an mobile api for an existing website and the client had told us to implement the api with various list of methods by looking to the existing website and so we need to analyze what are the queries to be framed.

    Now my actual question is,

    1. Is it possible to check that, what are the sql tables used behind and how are they joined by running different screens of website? (No stored procedures used and all are inline queries)
    2. If so how to check that, we have the rights to client's production and db server and apart from that we don't know anything.

    As a short i need to check, what are the TABLES used and how are they JOIN'ed by running every screens of website.

    Using SQL Profiler

    I had tried with SQL Profiler and it is returning large number of rows in where it is difficult to trace and after adding TextData filter by providing loginname i reduced the number of rows.

    Now it is returning like this in all rows exec sp_execute 8581,1,225 and when i run this am getting up this error Could not find prepared statement with handle 8581.

  2. #2
    Join Date
    Aug 2008
    Why not display all the "sp_prepare" statements - this should give you the information required.
    Are you running this in Query Analyzer? If so , you will also need to run the sp_prepare part above it , the pattern is :
    exec sp_prepare ..............................
    select @p1
    exec sp_execute ...............................

  3. #3
    Join Date
    Nov 2008
    How to do this with SQL Profiler ?
    Last edited by bharanidharanit; 02-04-13 at 02:33.

  4. #4
    Join Date
    Feb 2004
    In front of the computer
    Provided Answers: 54
    Quote Originally Posted by bharanidharanit View Post
    How to do this with SQL Profiler ?
    Search for the sp_prepare text within the trace file.

    SQL Profiler tracks the interaction between a SQL Server and its clients. Unfortunately, SQL Profiler only tracks those interactions over a fixed period of time, and some of the interactions may already be in progress when the trace starts, and others may not be complete when the trace ends.

    I most cases the point-in-time effect of the SQL Profiler trace isn't a problem, but it appears to be causing you trouble. In order to get a complete and fully repeatable trace you'll have to "cold start" the whole process to get a compleat and repeatable trace. There may be addiitional steps, but in general you'll want to do something like:
    1. Stop all servers (web, app, database, etc).
    2. Restart SQL Server
    3. Start the trace in SQL Profiler
    4. Start other servers
    5. Use every functionality and code branch within the existing app
    6. Shut down the servers (be sure to make SQL Server shut down last)
    7. Close the SQL Profiler trace.
    This probably seems complex, but it is necessary in order to ensure that you trap every interaction between the SQL Server and the client or clients.

    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts