• Steven Padfield (unregistered) 
        <FONT size=+0>DELETE FROM</FONT> HashIndex
     <FONT size=+0>WHERE</FONT> ItemHash >= (<FONT size=+0>SELECT MIN</FONT>(ItemHash) <FONT size=+0>FROM</FONT> HashIndex)
    is equivalent to
        <FONT size=+0>DELETE FROM</FONT> HashIndex

     <FONT size=+0>WHERE</FONT> ItemHash IS NOT NULL</PRE><PRE>&nbsp;</PRE></PRE>
  • Disgruntled DBA (unregistered)

    Holy crap!  This actually generates a different query plan than just delete or truncate.  It has two table scans for the price of one.  As long as we are deleting the whole table, let's do it in an extra expensive way.

  • (cs)

    Hey - You can never be too careful with those tricky hash indexes...

    I wonder if he did some traces and determined that was... well... no...

    You know, this one is just a scary look into an oddly formed mind...
    8-)

  • (cs)

    Perhaps he was trying (ineffectively) to deal with concurrency issues?

  • (cs)

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

  • Oisin G. (unregistered)

    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from

    " had a mandatory "where" clause.
  • (cs)

    I'd try something like

    DELETE FROM HashIndex WHERE ItemHash IN (SELECT ItemHash FROM HashIndex)

    Not sure if the syntax works but in principle it'd be even more wasteful.

  • (cs) in reply to Manni
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.
  • (cs) in reply to rogthefrog

    If you have access to the table schema and the right permissions, it might be faster to do a

    DROP TABLE IF EXISTS ItemHash;
    CREATE TABLE ItemHash (table def);

    if you're emptying the table completely.

  • (cs) in reply to Steven Padfield
    Anonymous:
        <font size="+0">DELETE FROM</font> HashIndex
         <font size="+0">WHERE</font> ItemHash >= (<font size="+0">SELECT MIN</font>(ItemHash) <font size="+0">FROM</font> HashIndex)
    is equivalent to
        <font size="+0">DELETE FROM</font> HashIndex
         <font size="+0">WHERE</font> ItemHash IS NOT NULL
     


    So the items with a null ItemHash value would be left in the table?  Which would make it different from deleting everything?  Assuming ItemHash isn't a required field?  Or am I totally off?  Its been a while since I've done much with SQL queries...
  • (cs) in reply to Joshie
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.
  • Your Name (unregistered) in reply to Steven Padfield

    Yes, keeping all the null values is most imporant

  • (cs) in reply to rogthefrog
    rogthefrog:
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.

    Apparently I've been one-upped, and then the one-upper was one-upped. Which means, according to my math, I've been two-upped. Now I have enough lives to find the princess, who is apparently in another castle.

  • (cs) in reply to Manni
    Manni:
    rogthefrog:
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.

    Apparently I've been one-upped, and then the one-upper was one-upped. Which means, according to my math, I've been two-upped. Now I have enough lives to find the princess, who is apparently in another castle.



    And then the one-upper shall become.. the one-uppee!!!111!!!!!!1
  • (cs) in reply to kipthegreat
    kipthegreat:
    Anonymous:
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash >= (<FONT size=+0>SELECT MIN</FONT>(ItemHash) <FONT size=+0>FROM</FONT> HashIndex)
    is equivalent to
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash IS NOT NULL
     



    So the items with a null ItemHash value would be left in the table?  Which would make it different from deleting everything?  Assuming ItemHash isn't a required field?  Or am I totally off?  Its been a while since I've done much with SQL queries...

    You're spot on. Null is not >= anything, nor is it < anything. The code therefore deletes all records that do not have a null ItemHash value.

  • (cs)

    Don't you know DELETE is faster when you delete rows by the INDEX?

    Idiots.

  • (cs)
    Alex Papadimoulis:

        <font color="#000099">DELETE FROM</font> HashIndex
         <font color="#000099">WHERE</font> ItemHash >= (<font color="#000099">SELECT MIN</font>(ItemHash) <font color="#000099">FROM</font> HashIndex)
    Wrapping the arm around the head just to eat the banana.
  • (cs) in reply to Manni
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.



    I always wondered what those stupid zen gardens were for.  After hearing this, I rank them up there with the abacus.
  • Cant count (unregistered) in reply to icelava

    FIRST!

  • (cs)

    Duh. Everyone knows a plain old TRUNCATE operates WAY TOO QUICKLY. This coder is obviously paid by the CPU cycle.

  • (cs) in reply to Your Name
    Anonymous:
    Yes, keeping all the null values is most imporant


    Especially if the table looks like:

    <font size="4">HashIndex    as type varchar;(umm, I guess)</font>
    <font size="4">Data as type Blob;
    </font>
    That way you can clog up your database with things you can't locate!

  • captcha! (unregistered) in reply to rogthefrog
    rogthefrog:
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.
  • captcha! (unregistered) in reply to captcha!

    god this forum software sucks...

    rogthefrog:
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.

     

    You guys must be regular posters on Slashdot.   http://en.wikipedia.org/wiki/Slashdot_subculture

  • WhatTheFark (unregistered)

    Quite obviously, the WTFery is that he used a subselect. He should have used a self join and having clause:

    DELETE FROM HashIndex hi1, HashIndex hi2
    WHERE hi1.ItemHash = hi2.ItemHash
    GROUP BY ItemHash
    HAVING hi2.ItemHash >= min(hi2.ItemHash)

    * wonder if that would even work. Probably not. I was just amused by the idea.


  • Ben Cooke (unregistered) in reply to Oisin G.
    Anonymous:
    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from" had a mandatory "where" clause.
    Personally, I wish that it did.

    It's pretty poor language design to make it much easier to do bad things than what you probably wanted to do. SQL is full of cases like this.

    We've seen how it's much easier to delete everything than it is to delete one particular row. It's also much easier to select everything -- which is usually quite an expensive operation -- than it is to select a particular row by its primary key or to retrieve a limited number of rows, or to retrieve only a subset of the columns. It's much easier to clobber an entire column of data than to change a field in a particular row.

    Crazy.

  • (cs) in reply to captcha!
    Anonymous:

    god this forum software sucks...

    rogthefrog:
    Joshie:
    Manni:

    Fourth! Or fifth...I'm not sure, maybe neither of those...nevermind.

    Databases are stupid. Back in my day, you had to write the one's and zero's out with a stick in a small box of sand sitting on your desk. Kids got it so easy these days.

    You got a box of sand? Lucky. I had to use my fingers and toes, so not only were my databases small, if I fell asleep or became distracted I could lose all of my data.


    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.

     

    You guys must be regular posters on Slashdot.   http://en.wikipedia.org/wiki/Slashdot_subculture



    You must be a youngster.
    http://www.phespirit.info/montypython/four_yorkshiremen.htm

  • Matt (unregistered) in reply to kipthegreat
    kipthegreat:
    Anonymous:
        <font size="+0">DELETE FROM</font> HashIndex
         <font size="+0">WHERE</font> ItemHash >= (<font size="+0">SELECT MIN</font>(ItemHash) <font size="+0">FROM</font> HashIndex)
    is equivalent to
        <font size="+0">DELETE FROM</font> HashIndex
         <font size="+0">WHERE</font> ItemHash IS NOT NULL
     


    So the items with a null ItemHash value would be left in the table?  Which would make it different from deleting everything?  Assuming ItemHash isn't a required field?  Or am I totally off?  Its been a while since I've done much with SQL queries...


    Items with a null ItemHash would be left in the table anyways. That's the great thing about null, is that it doesn't evaluate to anything. Try:
    select 1 where 1 <= null or 1 >=null
    Should return nothing.
  • ZeoS (unregistered)
    Alex Papadimoulis:

    Continuing with this week's series of "punch line code" samples, I wanted to share with you this small bit of T-SQL that Tracy McKibben uncovered. It's from the same codebase that we all peeked into a number of weeks back. Anyway, if you needed a command that would delete all rows from a specific table, you'd probably do something like this: 

        <font color="#000099">DELETE FROM</font> HashIndex

    Or, maybe this: 

        <font color="#000099">TRUNCATE TABLE</font> HashIndex

    Both do the job, each behaving specially in its own special way. Tracy's colleague, however, was satisfied with neither; he wanted to extra careful not to delete rows that didn't exist ... 

        <font color="#000099">DELETE FROM</font> HashIndex
         <font color="#000099">WHERE</font> ItemHash >= (<font color="#000099">SELECT MIN</font>(ItemHash) <font color="#000099">FROM</font> HashIndex)


    This remembers me another SQL code I saw once:
    drop MyTable;
    create MyTable .....
    :#
  • (cs) in reply to Oisin G.
    Anonymous:
    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from" had a mandatory "where" clause.


    This is actually true in MySQL (insert MySQL flames here) if you use the --I-am-a-dummy flag.
  • (cs) in reply to Ben Cooke
    Anonymous:
    It's pretty poor language design to make it much easier to do bad things than what you probably wanted to do. SQL is full of cases like this. We've seen how it's much easier to delete everything than it is to delete one particular row. It's also much easier to select everything -- which is usually quite an expensive operation -- than it is to select a particular row by its primary key or to retrieve a limited number of rows, or to retrieve only a subset of the columns. It's much easier to clobber an entire column of data than to change a field in a particular row. Crazy.


    SQL is like Unix in this regard - YAFI, YGI.  It's easier to delete everything because it's easier to say "delete everything", etc.


  • (cs) in reply to emurphy
    emurphy:
    Anonymous:
    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from" had a mandatory "where" clause.


    This is actually true in MySQL (insert MySQL flames here) if you use the --I-am-a-dummy flag.


    OMG it's real...
  • (cs)

    Look, everyone. There is no point trying to create sql statements even more inefficent code to delete rows. This guy wasn't even trying and he's beat us all already.

    No.

    What we REALLY need is procedural SQL with unidirectional cursors and a big outer repeat loop until the select count(*) from the table is zero to take it to the next level.

    Maybe lots and lots of commits just take make it extra special.

  • (cs)

    ah! I found the bug

    it should've been:

    DELETE FROM HashIndex
         <FONT size=+0>WHERE</FONT> isnull(ItemHash, 0) >= (<FONT size=+0>SELECT MIN</FONT>(isnull(ItemHash, 0)) <FONT size=+0>FROM</FONT> HashIndex (nolock))

    duh!!!

  • (cs) in reply to Xepol
    Xepol:
    What we REALLY need is procedural SQL with unidirectional cursors and a big outer repeat loop until the select count(*) from the table is zero to take it to the next level.

    Maybe lots and lots of commits just take make it extra special.



    Oh, and we should set all of the fields to the default value before deleting the row, to be more secure.

    And instead of hardcoding the fields in the SQL statement, we should query the system catalogs directly to find the field names.  Via a nested cursor.  Which should be deleted and recreated for each row.

    And to avoid excessive CPU load, there should be WAITFOR(...) statements on every other line.

  • (cs) in reply to Matt
    Anonymous:
    kipthegreat:
    Anonymous:
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash >= (<FONT size=+0>SELECT MIN</FONT>(ItemHash) <FONT size=+0>FROM</FONT> HashIndex)
    is equivalent to
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash IS NOT NULL
     



    So the items with a null ItemHash value would be left in the table?  Which would make it different from deleting everything?  Assuming ItemHash isn't a required field?  Or am I totally off?  Its been a while since I've done much with SQL queries...


    Items with a null ItemHash would be left in the table anyways. That's the great thing about null, is that it doesn't evaluate to anything. Try:
    select 1 where 1 <= null or 1 >=null
    Should return nothing.

    My personal favorite is: select 1 from dual/favorite-table where null = null

  • (cs) in reply to Xepol
    Xepol:
    Look, everyone. There is no point trying to create sql statements even more inefficent code to delete rows. This guy wasn't even trying and he's beat us all already. No. What we REALLY need is procedural SQL with unidirectional cursors and a big outer repeat loop until the select count(*) from the table is zero to take it to the next level. Maybe lots and lots of commits just take make it extra special.


    Ahhh, you are bringing me Oracle nightmares!!?!?!!?!!
  • (cs) in reply to Oisin G.
    Anonymous:
    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from" had a mandatory "where" clause.


    There are still better ways to delete everything:
    <font>
    DELETE FROM</font> HashIndex
         <font>WHERE</font> 1=1
    														</span><br>
  • nobody (unregistered)

    this code make my pet lead block look smart... I even feel like giving it a name.

  • nobody (unregistered) in reply to nobody
    Anonymous:
    this code make my pet lead block look smart... I even feel like giving it a name.

    I have succeded in naming my pet block of lead, as inspired by this code snip.

    I call it:

    "Unnamed Pet Block of Lead 1"

  • endothermal (unregistered)

    Just a note, truncate table, although effecient, requires some serious db rights.  In Sql Server requires more permissions then I am willing to give any application

    From books online

    Permissions

    TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable

    The reason why truncate table is so effecient is because the action or deletes are non-logged.  Which also means you cannot use truncate table on a database that is being replicated.  Also I have seen bugs in SQL Server version 7.0 transaction replication that when "delete from table" is run, not all of the deletes from the table are properly logged and perhaps the where clause was added to force the transaction log reader to see all of the deletes.   (Not that I am trying to defend the code)

     

     

  • Theo (unregistered) in reply to Daga
    Daga:
    Anonymous:
    ah, this isn't too bad to be honest. he/she is an obviously a relative newb to SQL and thought that "delete from" had a mandatory "where" clause.


    There are still better ways to delete everything:
    <font>
    DELETE FROM</font> HashIndex
         <font>WHERE</font> 1=1
    														</span><br></div></BLOCKQUOTE><br>


    <font>
    DELETE FROM</font> HashIndex
         <font>WHERE</font> 1

  • (cs) in reply to Xepol
    Xepol:
    Look, everyone. There is no point trying to create sql statements even more inefficent code to delete rows. This guy wasn't even trying and he's beat us all already. No. What we REALLY need is procedural SQL with unidirectional cursors and a big outer repeat loop until the select count(*) from the table is zero to take it to the next level. Maybe lots and lots of commits just take make it extra special.


    Actually, this is closer to truth than you think, at least in Oracle.
    Consider the situation where TRUNCATE TABLE is not possible, e.g. because of constraints. If the table is referenced by foreign key constraints, truncating is not possible, even if the referencing table is already empty. (You could disable the constraints, though)
    DROP TABLE+CREATE TABLE is also a bad idea for a lot of reasons.
    So, the easiest way to go is DELETE FROM MyTable without a WHERE clause.
    If you try that on table with 10000000 records, your rollback segments are most likely to small to do it.

    So, a working solution could look like that:

    loop
  delete from mytable where rownum<=10000;
  exit when sql%rowcount=0;
  commit;
end loop;

    This practice is even more common for UPDATE statements affecting more rows than the rollback segments can handle.

  • (cs) in reply to ammoQ

    my fault, once again

    loop
  delete from mytable where rownum<10000;
  exit when sql%rowcount=0;
  commit;
end loop;
  • (cs) in reply to OneFactor
    OneFactor:
    Anonymous:
    kipthegreat:
    Anonymous:
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash >= (<FONT size=+0>SELECT MIN</FONT>(ItemHash) <FONT size=+0>FROM</FONT> HashIndex)
    is equivalent to
        <FONT size=+0>DELETE FROM</FONT> HashIndex
         <FONT size=+0>WHERE</FONT> ItemHash IS NOT NULL
     



    So the items with a null ItemHash value would be left in the table?  Which would make it different from deleting everything?  Assuming ItemHash isn't a required field?  Or am I totally off?  Its been a while since I've done much with SQL queries...


    Items with a null ItemHash would be left in the table anyways. That's the great thing about null, is that it doesn't evaluate to anything. Try:
    select 1 where 1 <= null or 1 >=null
    Should return nothing.

    My personal favorite is: select 1 from dual/favorite-table where null = null

    This is logical as null basically means the absence of a value or an unknown/unspecified/undefined value. Comparing null to itself is like saying, "does some undefined value equal some other undefined value", which is indeterminate.

    As far as ordering goes, lets assume for a minute that null was less than or equal to a given value. Where exactly in the set of ordered values would null go?

    ...-3,-2,-1,null,0,1,2,3...?
    or
    ...-1,...,-0.1,...,-0.001,...,-0.000000001,...,null,0,...?

  • (cs) in reply to limelight
    limelight:

    This is logical as null basically means the absence of a value or an unknown/unspecified/undefined value. Comparing null to itself is like saying, "does some undefined value equal some other undefined value", which is indeterminate.

    As far as ordering goes, lets assume for a minute that null was less than or equal to a given value. Where exactly in the set of ordered values would null go?

    ...-3,-2,-1,null,0,1,2,3...?
    or
    ...-1,...,-0.1,...,-0.001,...,-0.000000001,...,null,0,...?


    Null is 22. I thought everyone knew that. I don't know what's wrong with language designers but I'm always having to use #define null 22 or public static final int null = 22. You'd think someone would get a clue! In the same way Empty is 22/3 and Nothing is -22/7.
  • (cs) in reply to limelight
    limelight:

    As far as ordering goes, lets assume for a minute that null was less than or equal to a given value. Where exactly in the set of ordered values would null go?

    ...-3,-2,-1,null,0,1,2,3...?
    or
    ...-1,...,-0.1,...,-0.001,...,-0.000000001,...,null,0,...?

    how about making it consistent with order by and making it less than every non-null value?

    select 1 foo from dual union select -1 from dual union select null from dual order by foo

    will put the null at the very top. That sure looks like null is "less than the minimum value". Which brings us full circle to null remains after deleting everything greater than or equal to the minimum [*-)]

  • (cs) in reply to rogthefrog

    rogthefrog:

    At least you had fingers and toes. Back in my day, I lived at the bottom of a lake, and giant monsters would come out and nibble on me fingers and toes till all I had left were stumps. I had to write my data schemas with me nose in the mud, and as soon as a carp stirred I lost everything and had to start all over again.

    Plus the mud was hosted by 1and1.

    Pffft... mud is easy. Back in my day, we only had one cell. That's right, one cell. Try keeping state on that.

    Damn newbies.

  • (cs)

    I prefer this:

    Select ItemHash from HashIndex where ItemHash >= (Select Miin(ItemHash) From HashIndex) into cursor hashesToDelete

    // forgive my non ansi sql, but I think you get the picture

    do until hashesToDelete.EOF
       delete from HashIndex where ItemHash = hashesToDelete.ItemHash
       hashesToDelete.fetchNext
    loop

  • Brian (unregistered) in reply to foxyshadis
    foxyshadis:
    limelight:

    This is logical as null basically means the absence of a value or an unknown/unspecified/undefined value. Comparing null to itself is like saying, "does some undefined value equal some other undefined value", which is indeterminate.

    As far as ordering goes, lets assume for a minute that null was less than or equal to a given value. Where exactly in the set of ordered values would null go?

    ...-3,-2,-1,null,0,1,2,3...?
    or
    ...-1,...,-0.1,...,-0.001,...,-0.000000001,...,null,0,...?


    Null is 22. I thought everyone knew that. I don't know what's wrong with language designers but I'm always having to use #define null 22 or public static final int null = 22. You'd think someone would get a clue! In the same way Empty is 22/3 and Nothing is -22/7.

    And I always thought null should be 42.

  • Oliver Townshend (unregistered)

    Encountered this at one site (sorry, syntax will be wrong)

     

    define cursor @table_del select id from table

    declare @id varchar(10)

    fetch @table_del into id

    while @@fetch_status=0 begin

       delete from table where id=@id

       fetch @table_del into id

    end

     

    I'm sure it also had stuff to make sure the cursor was unaffected etc. by the changes.  It took me several minutes of reading it before I realized what it was.

    Oliver Townshend

Leave a comment on “Greater Than or Equal to the Minimum”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article