|
Well if they don't get round to it for a few more days, you can fix it at contractor's rates!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I understand you.
I was in the same situation 1 1/2 years ago after being in the same place for exactly 10 years.
And just like you seem to feel now, I did not have any regrets leaving the place as most of the people I cared about had already left and the company was getting more and more worse...
...I never looked back, and never regretted leaving.
I wish you all the best, you close a chapter and open a new one.
Cheers!
|
|
|
|
|
Their loss! And ... you're probably getting paid more to boot!
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Congrats to the new job !
chriselst wrote: I shall be leaving home around 7 in the morning from now on
Because you got to get earlier there, or because it is further away from home ?
|
|
|
|
|
A bit of both.
And a lot of what Oz suggested.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
Crap. Thought you were starting a little poem.
Here I sit, broken hearted
Tried to sh!t
But only farted.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
|
..which is so much more helpful and logical than using the systems' settings..
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I think that I must have inherited my work PC from a previous user without being wiped first and thusly inherited their settings.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Oracle should not have the setting in the first place; there is a system setting.
Especially for the developer of a database-server, I'd expect that they'd at least know how idiotic it would be if you had to keep each setting per application for each workstation.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Oracle should not have the setting in the first place; there is a system setting.
I'm not arguing with that point. From a database development perspective, the only thing a user should have to be concerned with is 'Do I have the right connection string?' and 'Do I have the necessary permissions?'
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
This is why they invented ISO 8601. Can't we all just use YYYY-MM-DD ?
|
|
|
|
|
Probably for the same reasons you can't get Americans to use the metric system.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Americans?
I still can't think in litres, kilos, and kilometres, and I've been living in continental Europe for the past fifteen years!
Can't blame 'em for not using the metric system when everyone around them is not using it, too.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The metric system is used in much of America; it's only one largely insignificant portion of North America where you'll find the most hold-outs.
|
|
|
|
|
Hardly sporting to blame the database because somebody, at some point, made the dumb-assed decision to allow for implicit data conversion - passing a string literal and assuming that nobody would ever change environment settings.
Always, always, always, always use an explicit format mask for data conversions from string to date.
Did I mention "always"?
It's not hard.
you don't:
WHERE yourDatefield = :your_parameter --fingers crossed and hope it works!
Instead:
WHERE yourDatefield = TO_DATE(:your_parameter, 'YYYY/MM/DD') -- or whatever your string is formatted as.
|
|
|
|
|
I wasn't really blaming the database. It does what it is supposed to do, store data is a consistent and reliable format. I was more peeved at Oracle for not having any readily accessible documentation to help find some obscure registry key that causes string date conversions to fail just because they were out of an explicitly defined order.
Also, I totally agree that string literals for dates is never a good idea. I didn't write these scripts and they execute against production data so I wasn't about to go rewriting them on a whim just yet. I'll save that one for a later date.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
It's not the literals that are the problem - they have their uses. It's assuming that the database will format them the way you want that is the problem.
StackOverflow is chock-full-of-examples of people hitting that same problem.
Fortunately its an easy thing to not do, and once learned most people are pretty good about remembering.
Other than that, lots of perfectly good reasons to hate Oracle. It's been both my nemesis and paycheque for two decades now...lol.
|
|
|
|
|
What gets me is that I pulled up the registry settings on a pc that is known to successfully run the scripts and the offending key wasn't even there. Their system just defaulted to the server settings but because some previous owner of my work pc had explicitly set the date format in the registry, the scripts failed for me. Too many settings in too many locations makes for too many places for s**t to go wrong.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Which is why counting on implicit format mask settings is not recommended! None of those settings matter for anything other than display when you code with explicit conversions where you control the format mask. Otherwise, as you have discovered, you're walking an unknown dependency path waiting for someone else to set the default format for you!
Code with TO_DATE(string, mask) and the problem goes away - permenently!
|
|
|
|
|
Foothill wrote: I was more peeved at Oracle for not having any readily accessible documentation to help find some obscure registry key that causes string date conversions to fail just because they were out of an explicitly defined order. It's Chapter 15[^] in the Database Platform Guide.
|
|
|
|
|
Wow... that's spot on !
Thanks,
Milind
|
|
|
|
|
The secret to date literals in Oracle is to always use:
DATE'yyyy-mm-dd'
This format has worked with every SQL tool I have ever used. (At least 4)
|
|
|
|
|
|
Wow! I am weird but it looks like a ghost in red (the two outer spirals are arms)
|
|
|
|