The Daily WTF: Curious Perversions in Information Technology

2012-02-20 Reply Admin

ekolis:
zelmak:
SELECT CUSTOMER_ID_SEQ.NEXT_VAL FROM DUAL;
So DUAL really is the "dummy" table in Oracle? I did have a bit of Oracle training at my last job, but I didn't really believe the guy who was teaching when he said you had to select from DUAL if you wanted to just do calculations without any actual table data - why in the world would you need a dummy table? And even if you did, why would it be named DUAL?!?

The real WTF is that a table called dual has one row in it.

2012-02-20 Reply Admin

OK, I get that "select *" means "poor performance," but is that really a WTF-worthy article? We must really be scraping the bottom of the bad code samples barrel.

wbrianwhite · 2012-02-20 Reply Admin

xxx:
So you prefer INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
Now tell me how will you get the id of newly created customer? Select it by name or etc?

I don't know the particulars for oracle sequences. In Sql Server you just INSERT INTO CUSTOMERS (NAME, ETC ) VALUES (NewName, OtherInfo ); return scope_identity()

Or set an output var to the scope_identity(), whichever. If you don't have any history tables or triggers, a simple return @@IDENTITY will work. It's not rocket science.

30 seconds of googling found the equivalent for Oracle.

"The general syntax for the RETURNING clause is:

INSERT INTO

(c1, c2, .., cn) VALUES (v1, v2, .., vn) RETURNING <expression> INTO <variables> ... INSERT INTO Contacts (fname, sname) VALUES (pFirstname, pSurname) RETURNING ContactID INTO pContactID;"

2012-02-20 Reply Admin

John Preston:
Holy crap people, this is why we have NOT IN statements. Talk about taking the long way around.

For your reference, this made me giggle.

2012-02-20 Reply Admin

Severity One:
The stupid way would be to do "select max(id_customer)+1 from customer". They actually managed to find an even stupider way.
Come to think of it, though, this means that customer records must be pre-created. If you don't create the record first, you cannot enter a new customer.

Again, I ask: why?

Although the story talks about selecting the next available customer number, I'm not entirely convinced this was the actual purpose of this SQL. Aside from all else you only have to look at the first row of "customer_id !="'s to see that not all the numbers are there.

Still a WTF, not denying that, but I doubt the query was used quite as the story suggested.

2012-02-20 Reply Admin

Tim:
Severity One:
The stupid way would be to do "select max(id_customer)+1 from customer". They actually managed to find an even stupider way.
Come to think of it, though, this means that customer records must be pre-created. If you don't create the record first, you cannot enter a new customer.

Again, I ask: why?

the more i think about this, the less it makes sense. if the select statement is kept up to date to include all customers, it never returns any rows; if you first insert the new customer with a dummy ID (999999), the select will just return the dummy customer, but that doesn't help at all with allocating a new ID. I call a hoax on this one.

Exactly. It doesn't make sense to select * when we are creating a new record. It doesn't even make sense to look for a record we haven't made yet. If we are keeping track of exactly which customer numbers are not availabel (and therefore presumably updating the query when someone decides our system's too inefficient and moves to another vendor) it would be trivial to keep a list of availble customer numbers.

I can (almost) believe this sort of code exists somewhere in the universe, but the usage as presented in the article simply doesn't make sense. at all. even as a WTF.

2012-02-20 Reply Admin

(disclaimer: I am not very knowledgeable about databases.)

If they want to ensure they have a unique ID for each customer, but, as one commenter mentioned, it would be nice to do it in a way that allowed multiple concurrent users to not have collisions, why not simply use, say, the number of milliseconds since the epoch at the time the insert query is launched? The IDs won't be sequential, sure, but this guarantees they'll be unique, later customers will always have higher IDs, and you won't have stupid select queries like this one, which looks wrong even to talentless newbies.

I normally wouldn't care about captchas, but seeing 'Gravis' made me smile a bit (for all the old games that expected GUS and would go silent if you had a Soundblaster 16 :) )

2012-02-20 Reply Admin

F:
Steve The Cynic:
Lockwood:
In County Hyderabad, customer #12 office had accident.
[image]
Hyderabad is in Ireland?

Yes. It's pronounced "Cork". Irish spelling is a little strange.

yet somehow still more readable than Welsh - or pronouncable for that matter. I once had a coughing fit in a Welsh car yard while haggling with the salesman - Apparently I'd agreed to buy several cars by the time I'd finished, and offended 8 people passing by...

2012-02-20 Reply Admin

wbrianwhite:
It seems like a huge gaping lack of knowledge. If you DIDN'T KNOW that a customer insert proc could simply return the ID number it generated to the calling code, you might consider something vaguely approaching this. Not this. But something vaguely approaching this.

No.

Sequences are linear, so the number we returned should always be max(customer_id). Doing anything remotely like this is just stupid (assuming it is to find the most recent customer added)

2012-02-20 Reply Admin

Antony:
It's sad to see so many "fixed it" type comments advocating "max Id from table" and the like. Has no one here ever worked on a system with more than one concurrent user?

Well, this still isn't guaranteed to work for multiple users, though, is it?

Jim creates new Customer ACME industries (and takes his time filling in the details). The Customer is assigned ID 65789 Meanhile, Boris creates a new Customer Kresnovik Transport Concerns and quickly enters the detail. The customer is given 65790. When Boris uses this query to find his customer ID, he gets 65789 back. Depending on how and when the SQL gets updated (and to a degree how much Jim drags his feet), Jim could get 65789 (correctly) or 65790....

So neither method really works for concurrent users. I would have thought, given you just entered the customer detail, it would be reasonably trivial to query that detail...but maybe that's just me

zelmak · 2012-02-20 Reply Admin

xxx:
So you prefer INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
Now tell me how will you get the id of newly created customer? Select it by name or etc?

How do you get it with an auto-number field/column?

Addendum (2012-02-20 16:08): I mean, I'm no SQL-genius, but round-tripping to the database for a number that you probably don't need is silly. Now if you DO need that number ... :shrug:

Matt Westwood · 2012-02-20 Reply Admin

flikie:
F:
Steve The Cynic:
Lockwood:
In County Hyderabad, customer #12 office had accident.
[image]
Hyderabad is in Ireland?

Yes. It's pronounced "Cork". Irish spelling is a little strange.
yet somehow still more readable than Welsh - or pronouncable for that matter. I once had a coughing fit in a Welsh car yard while haggling with the salesman - Apparently I'd agreed to buy several cars by the time I'd finished, and offended 8 people passing by...

That's nothing - I farted in Arabia once and found out I'd proposed to my boss's daughter.

TheRider · 2012-02-20 Reply Admin

zelmak:
Must've been Oracle ... no autonumber, autoindex, autoincrement ... whatever ... fields.
They just needed to learn about sequences.
INSERT INTO CUSTOMERS ( ID, NAME, ETC ) 
  VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
My favorites, tho, are those yayhoos who do
SELECT CUSTOMER_ID_SEQ.NEXT_VAL FROM DUAL;
// do stuff to grab the number from the previous query
INSERT INTO CUSTOMERS ( ID, NAME, ETC )
  VALUES ( NewCustomerID, NewName, OtherInfo );

Well, the additional roundtrip would be necessary if you need to insert several rows into different tables that are dependent on each other. Such as like this:

SELECT CUSTOMER_ID_SEQ.NEXT_VAL FROM DUAL;
// do stuff to grab the number from the previous query
INSERT INTO CUSTOMERS ( ID, NAME, ETC )
  VALUES ( NewCustomerID, NewName, OtherInfo );
INSERT INTO ORDERS ( ID, CUSTOMERID, ORDERDATE, ...)
  VALUES ( ORDER_ID_SEQ.NEXT_VAL, NewCustomerId, SYSDATE, ...);

2012-02-20 Reply Admin

John Preston:
Holy crap people, this is why we have NOT IN statements. Talk about taking the long way around.

I don't care how many times you state "NOT IN", it won't keep me from going in wherever I please.

Though I may reach around just 'cause you're a good sport.

Coyne · 2012-02-20 Reply Admin

PiisAWheeL:
Smelge the Unsustainable:
I'm not a SQL bod so please forgive my naivety, but isn't this what Autonumber is for?
Or have I missed the point of what they're trying to achieve?

Who the hell knows what they were doing... It looks like they were trying to select all the column fields from a database, but manually skip the first 13 thousand some odd records (skipping a few numbers here and there). What they did with it after that is anybodys guess.

According to the story they used that code to create a new record for the next client, but that doesnt really make any sense unless they had a script get the next available record space and then automatically modify the code that stored the query. But yes, a simple AUTO_INCREMENT on database creation would have saved them a Metric Shit-ton of time and processing power for adding a new record to the database.

My guess is that they went to all this trouble so they wouldn't have to have an "activeCustomer" flag on the table. You know, one that would indicate the record was in use.

Which is still a horrid design.

But storing the active flag in the WHERE clause of an SQL query has to be a new high water mark in anti-patterns.

2012-02-20 Reply Admin

On the subject that this query might be used to get the last inserted id of an insert: There are WAY better ways to achieve this in a transaction than doing anything remote to that.

For example, off the top of my head I know that last_insert_id returns the id that the last insert statement generated in mysql. A google search resulted in @@IDENTITY for Sql Server. And I am quite optimistic that in all major databases some feature like this exists.

So there is no excuse to this query.

2012-02-20 Reply Admin

Antony:
It's sad to see so many "fixed it" type comments advocating "max Id from table" and the like. Has no one here ever worked on a system with more than one concurrent user?

This is the sort of thing, why I leave database stuff to someone else. Because it seems like a nice bright line of where to stop.

2012-02-20 Reply Admin

The use as suggested in the article indeed makes no sense, even as WTF. My guess is that this query is executed, but the result is ignored completely. The developer working there now (or the boss' nephew, w/e) is too afraid to throw it away and zealously keeps it up to date manually when customers are added or removed.

PiisAWheeL · 2012-02-20 Reply Admin

geoffrey:
OK, I get that "select *" means "poor performance," but is that really a WTF-worthy article? We must really be scraping the bottom of the bad code samples barrel.

You are trolling right? Like... did you miss the 4500 lines of while != code...? The select * is just the icing on this one.

2012-02-20 Reply Admin

TRWTF is that they didn't index the field and set the optimisation level to make this clever code run fast.

AmIright?

2012-02-20 Reply Admin

F:
Steve The Cynic::
Hyderabad is in Ireland?
Yes. It's pronounced "Cork". Irish spelling is a little strange.

THIS is why The Daily WTF needs a LIKE button.

2012-02-20 Reply Admin

waeg:
Antony:
It's sad to see so many "fixed it" type comments advocating "max Id from table" and the like. Has no one here ever worked on a system with more than one concurrent user?
Well, this still isn't guaranteed to work for multiple users, though, is it?
Jim creates new Customer ACME industries (and takes his time filling in the details). The Customer is assigned ID 65789 Meanhile, Boris creates a new Customer Kresnovik Transport Concerns and quickly enters the detail. The customer is given 65790. When Boris uses this query to find his customer ID, he gets 65789 back. Depending on how and when the SQL gets updated (and to a degree how much Jim drags his feet), Jim could get 65789 (correctly) or 65790....

So neither method really works for concurrent users. I would have thought, given you just entered the customer detail, it would be reasonably trivial to query that detail...but maybe that's just me

I wasn't saying either method works, they're both made of fail. People should learn how to use the tools a database gives them - every major db has a way of outputting identifiers after they're generated, and for anyone working with these platforms, it should be basic knowledge.

2012-02-20 Reply Admin

Antony:
waeg:
Antony:
It's sad to see so many "fixed it" type comments advocating "max Id from table" and the like. Has no one here ever worked on a system with more than one concurrent user?
Well, this still isn't guaranteed to work for multiple users, though, is it?
Jim creates new Customer ACME industries (and takes his time filling in the details). The Customer is assigned ID 65789 Meanhile, Boris creates a new Customer Kresnovik Transport Concerns and quickly enters the detail. The customer is given 65790. When Boris uses this query to find his customer ID, he gets 65789 back. Depending on how and when the SQL gets updated (and to a degree how much Jim drags his feet), Jim could get 65789 (correctly) or 65790....

So neither method really works for concurrent users. I would have thought, given you just entered the customer detail, it would be reasonably trivial to query that detail...but maybe that's just me

I wasn't saying either method works, they're both made of fail. People should learn how to use the tools a database gives them - every major db has a way of outputting identifiers after they're generated, and for anyone working with these platforms, it should be basic knowledge.

Oh, I get it, you were just offering a totally unrelated opinion?

2012-02-20 Reply Admin

Oracle has a returning clause that will hand you back a result set with the value in it.

2012-02-20 Reply Admin

The WTF was that they served ham sandwiches even though they knew he was Jewish......

2012-02-20 Reply Admin

PiisAWheeL:
geoffrey:
OK, I get that "select *" means "poor performance," but is that really a WTF-worthy article? We must really be scraping the bottom of the bad code samples barrel.

You are trolling right? Like... did you miss the 4500 lines of while != code...? The select * is just the icing on this one.

We have no context around the != code. It could be generated. The execution plan would look the same whether you include a myriad of inequality operators or a NOT IN statement. So what difference does it make how it looks? Neither has much asthetic appeal, anyway, so you pick a solution and go with it. That's no WTF, just reality.

2012-02-20 Reply Admin

Kind of surprised how many people here are not comfortable with:

Database generated id sequences Using transactions to select and update a handmade sequence table in one atomic step Returning data from a stored proc or insert statement Simply making CustomerId a GUID instead of a monotonically increasing sequence number

All these approaches have their benefits and drawbacks (as opposed to the approach found in the wild... which is full of fail). Depending on your situation you would choose different ones at different times...

Assigning an id to a business object reliably? This is bread and butter stuff!

2012-02-20 Reply Admin

The right way is just to generate a random customer ID. If there's a collision, well, you've been customer #524356 for long enough, it's time to let someone else have a go.

2012-02-21 Reply Admin

xxx:
So you prefer INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
Now tell me how will you get the id of newly created customer? Select it by name or etc?

INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo ) RETURNING id INTO some_variable;

Scarlet Manuka · 2012-02-21 Reply Admin

John Preston:
Holy crap people, this is why we have NOT IN statements. Talk about taking the long way around.

Nah, you can't use more than 1,000 values in a NOT IN clause. At least in Oracle.

ekolis:
So DUAL really is the "dummy" table in Oracle? [...] - why in the world would you need a dummy table? And even if you did, why would it be named DUAL?!?

It's derived from the usage of the term "dual" in mathematics. I suppose it simplifies the syntax parser if calculations take the same form as table queries.

herbie:
It doesn't make sense to select * when we are creating a new record. It doesn't even make sense to look for a record we haven't made yet.[...] I can (almost) believe this sort of code exists somewhere in the universe, but the usage as presented in the article simply doesn't make sense. at all. even as a WTF.

People complaining that it doesn't make sense to look for a new customer ID this way are overthinking it. Of course it doesn't make sense, but you shouldn't expect it to make sense, because there is no situation in which this query would make sense. Picking on "select *" is ridiculous - we see situations all the time on this site where "select *" is used to retrieve a single value. At least they put a WHERE clause in this query, even if it was a stupid one; that already puts them ahead of some of the contributions we've seen.

I can imagine a design that does things this way. It goes without saying that it's a horrible and broken design, of course. But I wouldn't rule the possibility out entirely.

2012-02-21 Reply Admin

bill:
Antony:
waeg:
Antony:
It's sad to see so many "fixed it" type comments advocating "max Id from table" and the like. Has no one here ever worked on a system with more than one concurrent user?
Well, this still isn't guaranteed to work for multiple users, though, is it?
Jim creates new Customer ACME industries (and takes his time filling in the details). The Customer is assigned ID 65789 Meanhile, Boris creates a new Customer Kresnovik Transport Concerns and quickly enters the detail. The customer is given 65790. When Boris uses this query to find his customer ID, he gets 65789 back. Depending on how and when the SQL gets updated (and to a degree how much Jim drags his feet), Jim could get 65789 (correctly) or 65790....

So neither method really works for concurrent users. I would have thought, given you just entered the customer detail, it would be reasonably trivial to query that detail...but maybe that's just me

I wasn't saying either method works, they're both made of fail. People should learn how to use the tools a database gives them - every major db has a way of outputting identifiers after they're generated, and for anyone working with these platforms, it should be basic knowledge.
Oh, I get it, you were just offering a totally unrelated opinion?

Well, if you define an opinion on the original code, and the suggested "solutions" as "unrelated", then I guess so.

2012-02-21 Reply Admin

TheRider:
Well, the additional roundtrip would be necessary if you need to insert several rows into different tables that are dependent on each other. Such as like this:
SELECT CUSTOMER_ID_SEQ.NEXT_VAL FROM DUAL;
// do stuff to grab the number from the previous query
INSERT INTO CUSTOMERS ( ID, NAME, ETC )
  VALUES ( NewCustomerID, NewName, OtherInfo );
INSERT INTO ORDERS ( ID, CUSTOMERID, ORDERDATE, ...)
  VALUES ( ORDER_ID_SEQ.NEXT_VAL, NewCustomerId, SYSDATE, ...);

Nope, you would write something like

INSERT INTO CUSTOMERS ( ID, NAME, ETC )
  VALUES ( CUSTOMERS_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
INSERT INTO ORDERS ( ID, CUSTOMERID, ORDERDATE, ...)
  VALUES ( ORDER_ID_SEQ.NEXT_VAL, CUSTOMERS_ID_SEQ.CURRVAL, SYSDATE, ...);

<SEQUENCE>.CURRVAL holds the last generated sequence number in your transaction (you will not get numbers generated by other users)

Severity One · 2012-02-21 Reply Admin

qwz:
xxx:
So you prefer INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
Now tell me how will you get the id of newly created customer? Select it by name or etc?
INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo ) RETURNING id INTO some_variable;

To 'xxx': if you learn something new from the comments of The Daily WTF, you shouldn't be posting here; rather, you should submit your own code so we can all have a good laugh.

2012-02-21 Reply Admin

You all seem to be missing the point of this query.

It actually makes perfect sense, iff the submitter has meaningful IDs and letting the database generate them would break something else. (Well, OK, maybe not perfect sense...)

My guess (FWIW) is somebody assigns the IDs by hand (perhaps for regulatory reasons), the tea boy updates the query accordingly, and nobody has any idea why - its just how it has always been done.

So TRRWTF has to be "using meaningful IDs as a primary key".

We now return you to your regular trolling.

2012-02-21 Reply Admin

The Real WTF is the guy that thought doing the "select max(id) from table" is safe when used in transactions but using transactions gets too "database-specific". LMAO

2012-02-21 Reply Admin

Jerry:
PiisAWheeL:
...a script get the next available record space and then automatically modify the code that stored the query.
Ahh, yes, you haven't lived until you've written some self-modifying code!
Go ahead, try it now.

You know you want to.

No one will ever know.

What could it hurt?

That's how Skynets get started

2012-02-21 Reply Admin

Are you from one of the DB Engine trade unions?

2012-02-21 Reply Admin

Antony:
ekolis:
zelmak:
SELECT CUSTOMER_ID_SEQ.NEXT_VAL FROM DUAL;
So DUAL really is the "dummy" table in Oracle? I did have a bit of Oracle training at my last job, but I didn't really believe the guy who was teaching when he said you had to select from DUAL if you wanted to just do calculations without any actual table data - why in the world would you need a dummy table? And even if you did, why would it be named DUAL?!?
The real WTF is that a table called dual has one row in it.

if you really want to screw things up add an extra row to the dual table. hilarity always ensues.

2012-02-21 Reply Admin

Not to mention != operator usually cannot use index. Sure it can. Why do you say that?

Because when that condition returns almost all rows, DB engine will not use such index, it would be pointless. Index will be used only when it shrinks result set significantly, otherwise just ignored and do the sequential scan.

2012-02-21 Reply Admin

xxx:
So you prefer INSERT INTO CUSTOMERS ( ID, NAME, ETC ) VALUES ( CUSTOMER_ID_SEQ.NEXT_VAL, NewName, OtherInfo );
Now tell me how will you get the id of newly created customer? Select it by name or etc?

Within the same transaction and immediately after the insert using NEXTVAL... SELECT CUSTOMER_ID_SEQ.CURRVAL FROM CUSTOMERS;

...should do it from what I cam tell from the docs here: Using Sequences

(Askimet bites whale dung)

2012-02-21 Reply Admin

This looks like someone who previously programmed SAT solvers migrated to SQL.

2012-02-21 Reply Admin

Lockwood:
In County Hyderabad, customer #12 office had accident.
[image]

And what did they do with the ATM after the "accident"?

Lockwood · 2012-02-21 Reply Admin

flikie:
F:
Steve The Cynic:
Lockwood:
In County Hyderabad, customer #12 office had accident.
[image]
Hyderabad is in Ireland?

Yes. It's pronounced "Cork". Irish spelling is a little strange.
yet somehow still more readable than Welsh - or pronouncable for that matter. I once had a coughing fit in a Welsh car yard while haggling with the salesman - Apparently I'd agreed to buy several cars by the time I'd finished, and offended 8 people passing by...

Please attempt some sensitivity. I had a son who was Welsh, and let me assure you: it is no laughing matter.

Anketam · 2012-02-21 Reply Admin

Tim:
Severity One:
The stupid way would be to do "select max(id_customer)+1 from customer". They actually managed to find an even stupider way.
Come to think of it, though, this means that customer records must be pre-created. If you don't create the record first, you cannot enter a new customer.

Again, I ask: why?
the more i think about this, the less it makes sense. if the select statement is kept up to date to include all customers, it never returns any rows; if you first insert the new customer with a dummy ID (999999), the select will just return the dummy customer, but that doesn't help at all with allocating a new ID. I call a hoax on this one.

Unless of course the customer table is prepopulated with ids and they are pulling ids from it to assign to new customers. <sarcasm>By not having to insert records into the customer table it will always be the same size, I think it is an excellent trade off.</sarcasm>

2012-02-21 Reply Admin

Antony:
ekolis:
why would it be named DUAL?!?

The real WTF is that a table called dual has one row in it.

It was designed as a two row table you were never supposed to directly query, which now only has one row in it, which doesn't receive any physical or logical IO, but you have to use it to obtain table-free results.

Can't make this stuff up. http://en.wikipedia.org/wiki/DUAL_table

QJo · 2012-02-21 Reply Admin

Bob:
Antony:
ekolis:
why would it be named DUAL?!?

The real WTF is that a table called dual has one row in it.

It was designed as a two row table you were never supposed to directly query, which now only has one row in it, which doesn't receive any physical or logical IO, but you have to use it to obtain table-free results.

Can't make this stuff up. http://en.wikipedia.org/wiki/DUAL_table

It never occurred to me that this is odd. It's just "the way to do this sort of thing" in Oracle's brand of SQL. Now you mention it, it does come across as somewhat idiosyncratic.

PiisAWheeL · 2012-02-21 Reply Admin

geoffrey:
PiisAWheeL:
geoffrey:
OK, I get that "select *" means "poor performance," but is that really a WTF-worthy article? We must really be scraping the bottom of the bad code samples barrel.

You are trolling right? Like... did you miss the 4500 lines of while != code...? The select * is just the icing on this one.

We have no context around the != code. It could be generated. The execution plan would look the same whether you include a myriad of inequality operators or a NOT IN statement. So what difference does it make how it looks? Neither has much asthetic appeal, anyway, so you pick a solution and go with it. That's no WTF, just reality.

!= or NOT IN is not the problem here. Its the manually skipping all the used record spaces. There is a plethora of solutions in my head I can think of that would use a quite a bit less processing power, quite a bit less code, and quite a bit less... WTF. Hell... I can think of about 7 different contexts that this code would be used in and come up with a solution that is much much better. This is the kind of solution you develop when you hate your client with a passion. Its almost a code bomb. If this is your idea of reality, then you sir, have a broken concept of what reality is.

2012-02-21 Reply Admin

Tim:
the more i think about this, the less it makes sense. if the select statement is kept up to date to include all customers, it never returns any rows; if you first insert the new customer with a dummy ID (999999), the select will just return the dummy customer, but that doesn't help at all with allocating a new ID. I call a hoax on this one.

Its obvious; the database uses an auto-increment. So they insert a row, the database assigns an ID, they then do a select with all known customer IDs. Whatever it returns must be the new one.

Manos · 2012-02-21 Reply Admin

It's obviously wrong. The proper way of doing it is to start from 1 every time and keep incrementing the id_customer until the primary key constraint stops throwing an Oracle error. It's the only way to be sure.

PiisAWheeL · 2012-02-21 Reply Admin

Manos:
It's obviously wrong. The proper way of doing it is to start from 1 every time and keep incrementing the id_customer until the primary key constraint stops throwing an Oracle error. It's the only way to be sure.

You win. There is no need to discuss this further... I about choked on spit laughing at that.

The Sentimental Query

Leave a comment on “The Sentimental Query”