|
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)
|
|
|
|
|
Cool!
Get me coffee and no one gets hurt!
|
|
|
|
|
How can heavy computing be cloud based?
[Bit early. Happy Easter.]
Life is too shor
|
|
|
|
|
|
I hear heavy metal in the air.
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
...could be a Led Zeppelin 
|
|
|
|
|
Let's say you compress a folder using WinZip or WinRAR with an AES256 encryption.
Let's say the password is 64 chars long (letters, numbers and special chars).
Would you trust this method to send sensitive and expensive data?
And if that file would be in not desired hands... how much effort would it take to decrypt it without the password?
Of course I don't expect receiving a precise answer like "yes, it will take 2 days and 34 seconds to decrypt the file..." just some comments and rough answers...
Thank you all!
|
|
|
|
|
My opinion based on what I have used so far - is that AES256[^] is perfectly safe for sending data.
Regarding a 64 char password, I don't see how you could communicate that outside on an email unless you write it down on paper and send it via courier. You could use a shorter password and be sure to communicate the password via a phone call or some other method that makes sniffing the data difficult.
In the past when I have worked with sensitive and expensive data, the data has always been handed over manually on an encrypted disk then the password has been communicated by phone(medical and patient data).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Joan Murt wrote: Would you trust this method to send sensitive and expensive data?
No.
Such a long password will not be remembered, meaning that someone will write it down on a post-it.
Joan Murt wrote: And if that file would be in not desired hands... how much effort would it take to decrypt it without the password?
If properly salted, too much to be worth the effort.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: If properly salted,
Don't forgett the pepper 
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
