I'm running a server side trace on SQL Server 2005 Enterprise and am receiving the below error:
Msg 19064, Level 16, State 1, Procedure sp_trace_create, Line 1
The requested trace stop time has been already passed.
I'm using this information as a test for this trace script, before I execute a formal server side trace. According to the site, I need a DATETIME variable (in this case #stop) which, if NULL, will continue endlessly. Below this is the pertinent code to this:
declare #rc int
declare #TraceID int
declare #maxfilesize bigint
declare #end datetime
set #maxfilesize = 20
set #end = NULL
exec #rc = sp_trace_create
#TraceID output
, 0
, N'\\MyFilePath\trace'
, #maxfilesize
, #end
, 100
if (#rc != 0) goto error
I also receive this same error message if I take the suggestion from the site about doing a time frame (like two hours), or if I do NULL (see above this). I do not receive an error if I set the parameter to 100, for instance, but I get another error message that states the following:
Msg 19064, Level 16, State 1, Procedure sp_trace_create, Line 1
The requested trace stop time has been already passed.
On top of that error, I don't receive any output files like this trace should generate. Note, that I am assuming that the parameter which is not valid is #end because when I change it to - what should be invalid - other values, it executes with a different error.
The remaining code, which shouldn't be pertinent to this error, is below:
-- Trace Events: REMOVED
-- Set the Filters
declare #intfilter int
declare #bigintfilter bigint
exec sp_trace_setfilter #TraceID, 10, 0, 7, N'SQL Server Profiler - 9cab2330-a33d-40d4-be59-cf5def384983'
-- Set the trace status to start
exec sp_trace_setstatus #TraceID, 1
--sp_trace_setstatus #traceid = 2, #status = 0 -- Trace stop
-- display trace id for future references
select TraceID=#TraceID
goto finish
error:
select ErrorCode=#rc
finish:
go
Set to 0 param to 2.
exec #rc = sp_trace_create
#TraceID output
, 2 -- THIS CHANGED FROM 0 to 2
, N'\\MyFilePath\trace'
, #maxfilesize
, #end
, 100 -- THIS NO LONGER GENERATES THE ERROR
My mistake, which was included on the site:
declare #rc int
declare #TraceID int
declare #maxfilesize bigint
declare #end datetime
set #maxfilesize = 20
set #end = NULL
exec #rc = sp_trace_create
#TraceID output
, 0
, N'\\MyFilePath\trace'
, #maxfilesize
, #end
, 100 -- THIS GENERATES THE ERROR
if (#rc != 0) goto error
When I remove the , 100, it runs fine. According to the site I originally referenced, this parameter limited the number of files created:
If you want to limit the number of files the trace creates - for
example, to 10 files - add 10 to the end of the parameter list . This
won’t stop the trace after it creates the number of files given for #
filecount. Instead, when the trace creates a new file, it deletes the
oldest file for this trace. So if you start off with Trace_1, Trace2 …
Trace_10, and then it creates Trace_11, Trace_1 will be deleted. This
keeps you from filling up your hard drive with trace files.
I'll keep researching why this parameter isn't accepted by the system (as it's useful to limit the number of files that are created), it may be a compatibility issue or something related to editions.
Related
I have a table fepu00 and trigger on it.
The part of code causing tha problem looks like follows:
if (old_record.potime = NEW.putime --new AP (read in statement above)
or old_record.pupisb::NUMERIC != NEW.pupisb::NUMERIC) then
insert into dl356_table
values (old_record.poid, old_record.poidma, old_record.ponmaf,
old_record.adstr, old_record.adpsc, old_record.adcit, old_record.adidze,
NEW.pupisb::numeric,
case when old_record.potime = NEW.putime then '1' else '2' end,
NEW.putime);
end if;
The query I'm executing is really simple:
update fepu00 set pudas = ? where puid = ?
It works, but only for some quantity of times. Then it throws:
ERROR: type of parameter 25 (numeric) does not match that when preparing the plan (text)
Where: PL/pgSQL function dl356_trigger() line 75 at IF
Number of updated records varies from a few to a few hundreds.
When I run the same query (with the same parameters) again, it works properly until the next fail.
Thanks for any suggestions.
I am trying to add a declared variable to replace a hardcoded list of values in a "where in" clause.
Researching how Hana handles array variables it seems like I can do this by declaring an array and then either using a select directly on it or by unnesting it first into a table but I keep getting errors I can't resolve.
When I try it this way:
DO
BEGIN
DECLARE CODES_ARRAY NVARCHAR(100) ARRAY = ARRAY('01','02','03','04');
SELECT T0."ItemCode"
FROM OITM T0
INNER JOIN OITW T1 ON T0."ItemCode" = T1."ItemCode"
WHERE "WhsCode" IN (SELECT "code" FROM :CODES_ARRAY); -- line 9 where error occurs
END;
I get this error message sql syntax error: incorrect syntax near ")": line 9 col 54 (at pos 239)
I can't figure out what the syntax error resolution is.
So then I tried inserting a declared table variable like this:
DO
BEGIN
DECLARE CODES_ARRAY NVARCHAR(100) ARRAY = ARRAY('01','02','03','04');
DECLARE CODES_TABLE TABLE = UNNEST(:CODES_ARRAY) AS ("code"); -- line 5 where error occurs
SELECT T0."ItemCode"
FROM OITM T0
INNER JOIN OITW T1 ON T0."ItemCode" = T1."ItemCode"
WHERE "WhsCode" IN (SELECT "code" FROM CODES_TABLE); -- I know : is missing here but when adding, the same error from previous block shows up
END;
and I get this error message: identifier must be declared: 1: line 5 col 38 (at pos 123)
As far as I can tell the array variable is declared as it should be so I don't know how to resolve the error.
I've read the SAP Hana SQL Reference documentation (for array/table variables, unnest function, etc.) over and over and it seems like I've got everything setup correctly but can't figure out these errors. I would like to be able to use both of these approaches at different times if possible (the "array variable to table variable" and the "array variable only" approaches)
I don't know exactly what is going on here, but one thing I notice that the two different error messages referenced in my post (see difference from errors in the first two code blocks) is that each error is occurring either immediately before the use of the variable with the : (in the case of the UNNEST) or immediately following the variable with the : (in the case of using in the SELECT * FROM in the query).
Because of that, I wondered if the issue is "upstream" at the Hana ADO.NET application query preparation and execution call level, but I ran a test and when I double checked the query string just before it is executed, it appears unchanged and the variables with : still look as they should, so at least as far as just before execution through Hana ADO.NET HanaCommand it looks correct - but once executing the query using HanaDataReader or HanaDataAdapter it returns the error messages referred to above. It may be a red herring to chase the problem from the Hana ADO.NET level but don't know what else to do.
Update
To further troubleshoot, I tried executing this code block below using hdbsql.exe -n XXX.XXX.XXX.XXX:30015 -u XXX -p XXX -m -I "c:\temp\test.sql" -c "#" and it works! So, the errors I see only show up when executing the same query through the Hana ADO.NET interface.
DO
BEGIN
DECLARE CODES_ARRAY NVARCHAR(10) ARRAY = ARRAY('01','02','03','04');
DECLARE CODES_TABLE TABLE ("code" NVARCHAR(10)) = UNNEST(:CODES_ARRAY) AS ("code");
SELECT T0."ItemCode"
FROM OITM T0
INNER JOIN OITW T1 ON T0."ItemCode" = T1."ItemCode"
WHERE "WhsCode" IN (SELECT "code" FROM :CODES_TABLE); -- line 10 where error occurs when using Hana ADO.NET
END;
#
The above fails when through Hana ADO.NET with the error message: sql syntax error: incorrect syntax near ")": line 10 col 54 (at pos 325) but works when executed through hdbsql.
Update
The C# code that executes the query is fairly straight forward, but for completeness of troubleshooting effort I am including the interesting parts of our HanaHelper class. This code works successfully to execute 100s of queries a day without errors or problems. This is the first time where a variable of any type has been attempted to be declared or used in a query through this code and when the errors started showing up. As far as I can tell, the issue is tied to the use of the : when using the variable in the query.
public class HanaHelper
{
public HanaConnection objConn = null;
public HanaHelper(string ConnectionString)
{
try
{
objConn = new HanaConnection(ConnectionString);
}
catch (Exception e)
{
Console.WriteLine(#"Exception thrown by HanaConnection: {0}\n{1}", e.Message, e.InnerException);
}
}
public DataSet GetData(string strSQL)
{
using (HanaCommand objCmd = new HanaCommand(strSQL, objConn))
{
using (HanaDataAdapter objDA = new HanaDataAdapter(objCmd))
{
DataSet objDS = new DataSet();
try
{
objDA.Fill(objDS);
}
catch (Exception)
{
throw;
}
finally
{
// do something interesting regardless of success or failure
}
objConn.Close();
return objDS;
}
}
}
}
Any clue here why the same query works through hdbsql but fails when executing through Hana ADO.NET?
Update
I figured out how to use HanaSQLTrace in the C# code so that I can inspect the prepared query text and viola, the source of error messages becomes apparent, all occurrences of ":VARNAME" are replaced with "? " (a ? replaces the : and a space for each character in the variable name). I suppose it is trying to pre-substitute occurrences of : with a ? as if there were parameters to be substituted.
How can this behavior be disabled, or worked with, or worked around so that I can use variables in a query in Hana ADO.NET effectively?
Updated based on the OP feedback.
To refer to a variable (in order to access its value(s)) in SQLScript it's
necessary to put a colon : in front of the variable name.
The main issue, however, turns out to be the declaration of the CODES_TABLE table variable.
With HANA 2 SPS 4 the error message is
`SAP DBTech JDBC: [264]: invalid datatype: unknown type SYSTEM.TABLE: line 5 col 23`
This points to the declaration of the TABLE typed variable CODES_TABLE which lacks the definition of what columns should be in the table.
Adding this fixes the issue.
With these changes, your code should work:
DO
BEGIN
DECLARE CODES_ARRAY NVARCHAR(100) ARRAY = ARRAY('01','02','03','04');
DECLARE CODES_TABLE TABLE ("code" NVARCHAR(100)) = UNNEST(:CODES_ARRAY) AS ("code");
-- ^^^^^^^^^^^^^^^^^^^^^^
-- |
---------------------------------------+
SELECT
T0."ItemCode"
FROM
OITM T0
INNER JOIN OITW T1
ON T0."ItemCode" = T1."ItemCode"
WHERE
"WhsCode" IN (SELECT "code" FROM :CODES_TABLE);
-- ^
-- |
---------------------------------------+
END;
An alternative option to declare and assign the table variable is to not use the DECLARE command.
DO
BEGIN
DECLARE CODES_ARRAY NVARCHAR(100) ARRAY = ARRAY('01','02','03','04');
CODES_TABLE = UNNEST(:CODES_ARRAY) AS ("code");
SELECT
T0."ItemCode"
FROM
OITM T0
INNER JOIN OITW T1
ON T0."ItemCode" = T1."ItemCode"
WHERE
"WhsCode" IN (SELECT "code" FROM :CODES_TABLE);
END;
I have written a cursor to search through a table looking at one bit value.
If all values are 1, I send an email. But if one value is 0 in any row, I don't send the email. The issue that I am having comes in my If statement. In SSMS, "#isComplete = 0" is breaking with only an "Incorrect syntax" error. I am not sure what I am missing here. My code is below. Thank you.
-------------------------------------------------
-- Start the INNER Cursor --
-------------------------------------------------
DECLARE #Complete int
DECLARE #isComplete Bit = 1
DECLARE INNERCur CURSOR FOR
SELECT Complete
FROM #AAEAPVS
OPEN INNERCur
FETCH NEXT FROM INNERCur INTO #Complete
WHILE ##FETCH_STATUS = 0
BEGIN
If #Complete = 0
BEGIN
#isComplete = 0
END
FETCH NEXT FROM INNERCur INTO #Complete
END
CLOSE InnerCurs
DEALLOCATE InnerCurs
-------------------------------------------------
-- INNER Curser END --
-------------------------------------------------
The incorrect syntax is that you need to use SET to assign the variable value, so change
#isComplete = 0
to
SET #isComplete = 0
And assuming you want to exit as soon as you find something that is not complete you should change your WHILE condition to
WHILE ##FETCH_STATUS = 0 AND #isComplete = 1
But most important of all, you probably don't need to use a cursor at all - you should avoid cursors in SQL if possible. You can probably just do something like this
DECLARE #isComplete Bit = 1
IF EXISTS (SELECT * FROM #AAEAPVS WHERE Complete = 0)
BEGIN
SET #isComplete = 0
END
and even that is more than you need, you can do it in a single statement
DECLARE #isComplete Bit = 1
SELECT #isComplete = 0 FROM #AAEAPVS WHERE Complete = 0
The syntax error results from not having a statement on the line. You need to use either SET or SELECT to assign a value to a variable, e.g. set #isComplete = 0.
Why, pray tell, a cursor rather than a simple EXISTS query? A far more efficient solution is:
select #isComplete = case
when exists ( select 42 from #AAEAPVS where Complete = 0 ) then 0
else 1 end;
Tip: It is helpful to tag database questions with both the appropriate software (MySQL, Oracle, DB2, ...) and version, e.g. sql-server-2014. Differences in syntax and features often affect the answers.
I have written some code to ensure that items on an order are all numbered (the "position number" or "item number" has been introduced only recently and we did not want to go and change all related code - as it is "asthetics only" and has no functional impact.)
So, the idea is to go and check for an records that jave an itemno of NULL or 0 - and then compute one and assign it. When executing this code in a query window, it works fine. When putting it into an AFTER INSERT-trigger, it loops forever.
So what is wrong here?
/****** Objekt: Trigger [SetzePosNr] Skriptdatum: 02/28/2010 20:06:29 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TRIGGER [SetzePosNr]
ON [dbo].[bestellpos]
AFTER INSERT
AS
BEGIN
DECLARE #idb int
DECLARE #idp int
DECLARE #pnr int
SELECT #idp=id,#idb=id_bestellungen FROM bestellpos WHERE posnr IS NULL OR posnr=0
WHILE #idp IS NOT NULL
BEGIN
SELECT #pnr = 1+max(posnr) FROM bestellpos WHERE id_bestellungen = #idb
print( 'idp=' + str(#idp) + ', idb=' + str(#idb) + ', posnr=' + str(#pnr))
UPDATE bestellpos SET posnr=#pnr WHERE id=#idp
SELECT #idp=id,#idb=id_bestellungen FROM bestellpos WHERE posnr IS NULL OR posnr=0
END
END
Aaaargh - just found the problem: the 3d line (from the end, the SELECT-statement) does not assign the variables when there result of the WHERE is NULL. So "set #idp=null" before that statement has fixed the problem!
Not sure whhy I assumed a problem between direct execution and triggering of these statements, seems I picked the wrong test-cases :(
I have a REXX job that needs to read from both Teradata (using BTEQ) and DB2. At present, I can get it to either read from Teradata or DB2, but not both. When I try to read from both, the Teradata one (which runs first) works fine but the DB2 read gives an error of RC(1) upon attempting to open the cursor.
Code to read from Teradata (by and large copied from http://www.teradataforum.com/teradata/20040928_131203.htm):
ADDRESS TSO "DELETE BLAH.TEMP"
"ALLOC FI(SYSPRINT) DA(BLAH.TEMP) NEW CATALOG SP(10 10) TR RELEASE",
"UNIT(SYSDA) RECFM(F B A) LRECL(133) BLKSIZE(0) REUSE"
"ATTRIB FBATTR LRECL(220)"
"ALLOC F(SYSIN) UNIT(VIO) TRACKS SPACE(10,10) USING(FBATTR)"
/* Set up BTEQ script */
QUEUE ".RUN FILE=LOGON"
QUEUE "SELECT COLUMN1 FROM TABLE1;"
/* Run BTEQ script */
"EXECIO * DISKW SYSIN (FINIS"
"CALL 'SYS3.TDP.APPLOAD(BTQMAIN)'"; bteq_rc = rc
"FREE FI(SYSPRINT SYSIN)"
/* Read and parse BTEQ output */
"EXECIO * DISKR SYSPRINT (STEM BTEQOUT. FINIS"
DO I = 1 to BTEQOUT.0
...
END
Code to read from DB2:
ADDRESS TSO "SUBCOM DSNREXX"
IF RC THEN rcDB2 = RXSUBCOM('ADD','DSNREXX','DSNREXX')
ADDRESS DSNREXX "CONNECT " subsys
sqlQuery = "SELECT COLUMN2 FROM TABLE2;"
ADDRESS DSNREXX "EXECSQL DECLARE C001 CURSOR FOR S001"
IF SQLCODE <> 0 THEN DO
SAY 'DECLARE C001 SQLCODE = ' SQLCODE
EXIT 12
END
ADDRESS DSNREXX "EXECSQL PREPARE S001 FROM :sqlQuery"
IF SQLCODE <> 0 THEN DO
SAY 'PREPARE S001 SQLCODE = ' SQLCODE SQLERROR
EXIT 12
END
ADDRESS DSNREXX "EXECSQL OPEN C001"
IF SQLCODE <> 0 THEN DO
SAY 'OPEN C001 SQLCODE = ' SQLCODE
EXIT 12
END
ADDRESS DSNREXX "EXECSQL FETCH C001 INTO :col2"
IF SQLCODE <> 0 THEN DO
SAY 'FETCH C001 SQLCODE = ' SQLCODE
EXIT 12
END
I suspect that this has something to do with my use of SYSPRINT and SYSIN. Anyone know how I can get this to work?
Thanks.
Edit
The question as stated was actually wrong. Apologies for not correcting this earlier.
What I had really done was have this:
ADDRESS TSO "SUBCOM DSNREXX"
IF RC THEN rcDB2 = RXSUBCOM('ADD','DSNREXX','DSNREXX')
ADDRESS DSNREXX "CONNECT " subsys
...followed by a small read from DB2, then followed by the code to read from Teradata, followed by more code to read from DB2. When this was changed to reading from Teradata first before having anything to do with DB2 at all, it worked.
I don't think this has anything to do with SYSPRINT or SYSIN.
I think you are getting TSO RC = 1, not SQLCODE = 1 (because there is no SQLCODE of 1.
1 is a warning, -1 is an error. You can look this up in the DB2 Application Programming
and SQL Guide
Turn on TRACE R and run it.
There are variables (shown below) that display info about the error/warning.
22 *-* ADDRESS DSNREXX "EXECSQL OPEN C1"
>>> "EXECSQL OPEN C1"
+++ RC(1) +++
23 *-* IF SQLCODE <> 0
28 *-* SAY 'SQLSTATE='sqlstate', SQLERRMC='sqlerrmc', SQLERRP='sqlerrp
SQLSTATE=00000, SQLERRMC=, SQLERRP=DSN
29 - SAY 'SQLERRD='sqlerrd.1', 'sqlerrd.2', 'sqlerrd.3', 'sqlerrd.4',',
sqlerrd.5', 'sqlerrd.6
SQLERRD=0, 0, 0, -1, 0, 0
32 - SAY 'SQLWARN='sqlwarn.0', 'sqlwarn.1', 'sqlwarn.2', 'sqlwarn.3',',
sqlwarn.4', 'sqlwarn.5', 'sqlwarn.6', 'sqlwarn.7',',
sqlwarn.8', 'sqlwarn.9', 'sqlwarn.10
SQLWARN= , N, , , , 2, , , , ,
For example, it could be that when both are used together, there is not enough memory.