I am aware of some ways for seeing the recent queries for the current database, such as:
SELECT deqs.last_execution_time AS [Time], dest.text AS [Query], dest.*
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE dest.dbid = DB_ID()
ORDER BY deqs.last_execution_time DESC
My problem is that the results aren't showing the values being passed to the PROC, but are instead showing the names of the parameters. I already know the name of the PROC and I have the script. I need to know what a particular ASP app is passing in.
For now I just have the PROC INSERTing the param values into a logging table, but I was wondering if there was a better way.
Try to use custom logging in the stored procedure. Whenever the stored procedure is invoked, log an entry into the log table with the passed in params.
Related
I am using ASP.NET Web Forms. I am trying to bind some data from a previous page (including the URL and some specific figures stored in the URL) to session variables for use in a SQL insert statement to a SQL Server database.
An example of one of the assignments is below:
this.Session["URL"] = HttpUtility.ParseQueryString(Request.UrlReferrer.Query)["helpurl"];
The problem I am having is that on executing the SQL insert, the value does not seem to be present and the default value is recorded. SessionState is enabled. I am able to print the result of the HttpUtility method to a label, and I am also able to assign to session variables for a SQL statement if I assign them directly, eg:
this.session["Variable"] = Variable;
Any ideas why the result of the HttpUtility function may not be assigned to the session variable prior to the execution of the SQL insert statement?
It's ok - I placed the assignments inside an
if(!IsPostBack)
And they now work ok and are being recorded to the database. I also removed the 'this' keyword from them.
Thanks anyway
I need to parameterize a view, and I am doing so by creating a TEMP TABLE which has the parameters for the view.
CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
CREATE VIEW tableview AS ...
The VIEW is rather complex, but it basically uses these two parameters to kick start a recursive CTE, and there isn't any other way that I have found to express the view without these parameters.
The parameters must be stored in a temporary table because each connection should be able to have its own view with different parameters.
In any case, this works fine for creating the view itself, so long as I create the same TEMP TABLE at the start of any queries that use the view, e.g.:
CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
INSERT INTO parms (parm1,parm2) VALUES (5,66);
SELECT * FROM tableview;
I am able to do the same thing to create a trigger to allow inserts on the view:
CREATE TEMP TABLE parms (parm1 INTEGER, parm2 INTEGER);
CREATE TRIGGER tableinsert INSTEAD OF INSERT ON tableview ...
However, when I try to do an actual INSERT (re-creating the TEMP TABLE first as before) I get an error:
no such table: main.parms
If I create a non-temporary table, I do not get this error, but then I have the problem that different connections can't have their own separate views.
I have review the documentation for triggers, and it mentions caveats of using temporary triggers on a non-temporary table, but I don't see anything regarding the reverse.
I did find a reference elsewhere that indicated that "the table... must exist in the same database as the table or view to which the trigger is attached". I thought a temporary table was part of the current database, is this not true? Is there some way to make this true?
I also tried accessing the parms table as temp.parms in the TRIGGER, but got the error:
qualified table names are not allowed on INSERT, UPDATE, and DELETE
statements within triggers
If I can't use a temporary table, is there some way to work around it to accomplish the same thing?
Update: Ok, so it seems to be an SQLite limitation. After digging around a bit in the SQLite source code, it seems to be pretty trivial to allow SELECT access to a temporary table in a trigger. However, allowing UPDATE access appears to be a lot harder.
Temporary objects are created in a separate database named temp, so they are not accessible from triggers in other databases.
The remaining mechanism to get a connection-specific value into a trigger is to use a user-defined function.
I have a trigger ON UPDATE on a table that calls a custom function. In the custom function, I want to insert into a log table the name of the current SAVEPOINT (the deepest unsaved one) along with the name of the table and the timestamp. I am currently hardcoding the name of the table (please let me know if there is a better way) but I cannot figure out how to get the name of the current SAVEPOINT.
Thanks!
By default, SQLite has no functions to get the current savepoint (or the current trigger's table).
However, if you have compiled SQLite into your application, you could use sqliteInt.h, and, from a variable sqlite3 *db, access the current savepoint's name as db->pSavepoint->zName.
One way to determine current save point, without resorting to using sqlite3int.h and the sqlite3* db structure is to set up a compile time authorization callback (http://www.sqlite.org/c3ref/set_authorizer.html) and then look for an action code (http://www.sqlite.org/c3ref/c_alter_table.html) of SQLITE_SAVEPOINT.
The fourth parameter passed to the authorizer callback will be the name of a savepoint. By storing this name in your structure - you will have access to the name of the last save point passed in during analysis/preparation of your sqlite3_stmt.
I want to restrict the execution of my PL/SQL code from repetition. That is, I have written a PL/SQL code with three input parameters viz, Month, Year and a Flag. I have executed the procedure with the following values for the parameters:
Month: March
Year : 2011
Flag: Y
Now, If I am trying to execute the procedure with the same values to the parameters as above, I want to write some code in the PL/SQL to restrict the unwanted second execution. Can anyone help. I hope the question is no ambiguous.
You can use the function result cache: http://www.oracle-developer.net/display.php?id=504 . So Oracle can do this for you.
I would create another table that would store the 3 parameters of each request. When your procedure is called it would first check the "parameter request" table to see if the calling parameters have beem used before. If found, then exit the procedure. If not found, then save the parameters and execute the rest of the procedure.
Your going to need to keep "State" of the last call somewhere. I would recommend creating a table with a datetime column.
When your procedure is called update this table. So, next time when your procedure is called.. check this table to see when was the last time your procedure was called and then proceed accordingly.
Why not set up a table to track what arguments you've already executed it with?
In your procedure, first check that table to see if similar parameters have already been processed. If so, exit (with or without an error).
If not, insert them and do the processing necessary.
Depending on how tight the requirements are, you'll need to get a exclusive lock on that table to prevent concurrent execution.
A nice plus would be an extra column with "in progress"/"done"/"error" status so that you can check if things are going on properly. (Maybe a timestamp too if that's important/interesting.)
This setup allows you to easily clear some of the executions (by deleting some rows) if you find things need to be re-done for whatever reason.
Make an insert in the beginning of the procedure, and do a select for update tolock the table so no one else can process any data and if everything goes ok with the procedure, commit and release the table 😀
I currently have multiple queries that query data from a few tables linked through ODBC, and some temporary tables that are edited through the user interface. I have complex criteria in my queries such as:
SELECT * from ThingsData
WHERE (Thing In(SELECT Thing from ListOfThings) AND getThingFlag() = True);
In this case Thing is a field and ListOfThings is a temporary table that the user defines from the user interface. Basically, the user puts together a list of the field Thing that he/she wants to filter the data based on and I want to query only the data that matches the Thing values that the user adds to his/her list. Currently, the data I am querying is in the linked ODBC table, and the temp table ListOfThings is just a regular, local table and everything works peachy. I want to get rid of the linked table and use a pass through query instead. However, when i do that, unless the criteria is incredibly simplistic, i get an error:
"ODBC--Call Failed. Invalid object name ListOfThings."
If I dont have any criteria it works fine.
Long story short: In a pass through query, how do I apply criterias that include SELECTs and functions from my modules and just basically filter the pass through table based on data from my local tables?
What is at the other end of that ODBC link? In a pass-through query you will have to honor the syntax required by the database server, not Access syntax. I would first suspect that you can't have mixed case table names and I would try listofthings as the name.
If you have a tool that can be used to test queries directly against the database server, get the query working there and then simply cut and paste it into an Access pass-through query.