DELETE in prod
-
Who is Tom and why do I want to ask him a question?
-
Oh sorry,
DELETE FROM TheTable Select * from TheTable;
Filed under: How am I 22% of the replies, what about the back-and-forth from @boomzilla and @blakeyrat?!
-
Response:
ORA-00933: SQL command not properly ended
-
DELETE FROM TheTable Select * from TheTable;
Same response:
Response: ORA-00933: SQL command not properly ended
The first one isn't properly ended. Oracle wouldn't run it.
-
Maybe. How would you implement this without a GUI?
Stop using shit from 1975 and join the rest of us here in 2015?
-
Who is Tom
Think it's where the guy from Myspace went after everyone stopped using that.
-
The first one isn't properly ended. Oracle wouldn't run it.
Yeah. Gotta put semicolons when you run two separate statements like that. Even javascript won't insert a semi-colon there!
-
join the rest of us here in 2015
I'll have you know we're fully in the current century!
Filed under: INB4: Back to the Future joke.
-
two separate statements
Ah, but that's where the whole things starts, isn't it? Wasn't meant to be two separate statements, so therefore the error is a red herring!
Filed under: Near 'FROM TheTable'
-
I'm not sure about SQL developer and friends, but in programmatic interfaces Oracle will never accept two queries in one go even when separated by semicolons. If you really want to you'll have to pass a PL/SQL block.
-
I'm not sure about SQL developer and friends
SQL Developer splits at the semicolon and runs them as separate statements.
Even running it with F5, it'd still pass the wholeDELETE FROM TheTable Select * from TheTable;
to the database and Oracle would error.
-
I'm not sure about SQL developer and friends, but in programmatic interfaces Oracle will never accept two queries in one go even when separated by semicolons.
Yes, putting multiple statements in an editor pane and running them is like being in a PL/SQL block. I normally run with F9 which only runs a single statement. It's rare that I want to use F5 and run everything (or a highlighted portion of everything).
It was mostly a "joke" about SQL dialects. And I can rarely resist taking a poke at javascript for being retarded about semi-colons.
But I do really like how Oracle connections won't allow a lot of the stupid stuff that results in SQL injection (i.e., semi-colons and comments).
-
comments
This reminds me of a (somewhat) recent developer-wide email that was sent out.
In it we were admonished to not use the "double-dash" form of commenting, but instead use a "flower box".Apparently, some script was being sent in a scheduled process that had said evil comments that crashed the whole server. And of course, the scheduler dutifully noticed that the scheduled process didn't run, so on boot it tried to run it again (and crashed the server again).
Since I'm not a DBA, I was just sitting at my desk wondering why our production servers couldn't stay running for more than a few minutes.
Filed under: Is it really injection if it's built into the source script?
-
fuck me. that is a terminal emulator inside a browser?
-
-
We also have an actual Terminal Emulator (3270 Terminal Emulator) that gets embedded as an ActiveX object inside a Silverlight object in a web page (but that's a different site).
That one has color!
Filed under: Yeah, we're modern and use a Web Front End! Just install this Client Program first!
-
Oracle connections won't allow [...] comments
I don't follow? Both /* in-line */ and -- rest-of-line comments are allowed.
-
Oh, yes, of course they are.
But, if you have a cruddy ODBC driver that faults as it's translating between SQL server to (somewhere else), then I guess they're not.
-
@boomzilla said:
Oracle connections won't allow [...] comments
I don't follow? Both /* in-line */ and -- rest-of-line comments are allowed.
Eh...you're right. Not sure what I was thinking. Definitely complains about semicolons though.
-
Yeah, apparently some sort of new regulation "mandates" that certain "personal information" be "obfuscated" in our Dev and Test servers. In theory it should work, after the "daily" refresh of production data into the test and dev environments, just use an obfuscation tables to update all the records to their expected obfuscated state.Too bad it doesn't work.
In my case, it's not PII. It's spatial data that may (or may not) be Classified.
It's data that has to be in a format that Oracle Spatial can use.
-
My bigger complaint is UPDATE statements where I'm so busy copying and pasting the GUIDs for the foreign keys or whatever that I forget to type the WHERE clause. Why didn't they just make it mandatory so you would have to type
WHERE 1=1
if you really, really, really wanted to touch ALL records at once?It's getting better in that I automatically type
UPDATE tbl_something SET WHERE
and only then start to fill in the columns and values. But still.
-
You write the WHERE clause first. ALWAYS.
-
I think mysql client does the 1=1 thing
-
Classified
I hope you don't mean classified because if you're mixing classified and unclassified data.......... you're gonna be in trouble.....
-
@powerlord said:
Classified
I hope you don't mean classified because if you're mixing classified and unclassified data.......... you're gonna be in trouble.....
I just know what I've been told.
Having said that, the data is for one of the state governments and not the federal government.
-
This looks like a pretty clear example of a bad interface.
You're about to run a DELETE statement. The following [n] records will be deleted: [scrolling list] [OK] [Cancel]
There, fixed it. I'll take my million dollars now etc.
Access does that, but MSSQL doesn't.
-