It only fails in production.
-
Can you guess why this line of SQL passes our test battery, works on our test system, works on our staging system, and fails on our outsourced production system?
INSERT INTO [clientdb].[dbo].[tbl_somestuff] (foo, bar) VALUES ('foo', 'bar')
If this post is less than intelligible, it's because it's now 10:30AM. I have been awake all night fixing this bug and pushing a new release through to fix it.
TRWTF is that I can't remove the gibberish that got pasted in at the top of this post. [I can. -- mod]
-
I'll fathom a guess and say... clientdb is not the name of the database on the production system. Either that or tbl_somestuff doesn't exist on the production system.
-
@Weng said:
outsourced
I'm going to guess this is most of your problem.My next guess is different schema in DEV/QA versus PROD, but that would be too obvious.
-
@belgariontheking said:
@Weng said:
This is usually most of the problem.outsourced
I'm going to guess this is most of your problem.
-
Easy: the outsourced production system is messed up.
-
@belgariontheking said:
My next guess is different schema in DEV/QA versus PROD, but that would be too obvious.
Second that. I've been dealing with a DEV/QA vs PROD situation like that for years.
-
Is it because the outsourced production system isn't a server at all, but is just an autorickshaw and a bowl of chicken curry?
-
@morbiuswilters said:
autorickshaw
Who would want an autorickshaw? Isn't the fun of a rickshaw that you can relax and watch other people struggle to accomplish soul-crushing manual labor to meet your whims?
-
Is it because ('foo', 'bar') is already a row in the production system?
-
@TGV said:
Is it because ('foo', 'bar') is already a row in the production system?
If that were true, I doubt he would have to release a fix. Presumably he could just delete that row.
-
Isn't the TRWTF here that he's asking for help on a website devoted to laughing at others' stupidity? There must hundreds of more helpful website where this kind of question would be treated seriously. Or am I missing the fact this is some kind of puzzle?
-
@belgariontheking said:
If that were true, I doubt he would have to release a fix. Presumably he could just delete that row.
Yes, but there's probably a company policy that says developers aren't allowed to have access to the Production database. Sensitive commercial or personal information, and all that. So he has to write a bit of code into the production executable which deletes that row. Then 2 years from now, someone tries to insert (foo,bar) and it immediately gets deleted and some other developer has to stay up all night going through an executable which is in Production but never made it into the source code repository.
Or, under the same policies, helpdesk changed the schema and the change was never propagated back to Dev/QA.
-
@jmucchiello said:
Isn't the TRWTF here that he's asking for help on a website devoted to laughing at others' stupidity?
No, he didn't ask for help. He specifically stated that he just stayed up all night fixing the problem, thus implying that he has already fixed it. He's simply sharing the stupidity with us.
-
There are any number of reasons why that query might fail on production. But I can't think of any that are particularly super-funny or neat so why don't you just tell us?
Something to do with grape jelly? *crosses fingers*
-
I reply because I might have dealt with this before...
Foo or Bar are not string fields in production. BOOYA! I am betting one is a number or date.
-
To silence the trolls: It explicitly refers to the testing database [clientdb], so it passes testing but fails in production.
-
I'm willing to bet the tables aren't actually owned by dbo on the production system.
-
My bet is that the outsourced company decided to "tighten up security" and started removing privileges until the database was unusable...The fix that needed to be built is a script to put back only the privileges that are actually required...
How close am I?
-
Either "The production system was replaced with an entirely different database type" or "The production server was secretly replaced with Folger's Crystals™."
-
The manager that oversees the production server decided to implement his own, far superior, database that is implemented using text files and an AutoIT script.
-
@Auction_God said:
Not even on the map. The first thing I checked was "Did this shithead ignore my permissions instructions?" and cross-checked every permission against different features. Every single thing in the entire application worked except this single query.My bet is that the outsourced company decided to "tighten up security" and started removing privileges until the database was unusable...The fix that needed to be built is a script to put back only the privileges that are actually required...
How close am I?
Indeed, the production name of the database is NOT the same as specified, and it isn't in dbo (despite my initial create scripts explicitly putting everything there. Magically, this one line is the only one in the entire application that someone managed to fully qualify the tablename.
-
Edit: Oh, apparently you've fixed it already. Since there's literally thousands of possible reasons why a given SQL statement may or may not work, I guess I don't really get the humor of this thread. If it's actually funny, why not post it?
