Re^5: DBIx::Simple and Oracle dates (stuff)

As I indicated in my OP the query works in SQL Developer.

Yeah, it is common for DBs to allow you to silently treat a date or datetime as a string, so you often won't get any warning or error for saying "sometime LIKE somedate". But doing that just converts 'somedate' to a string, treats any resulting '%' characters (surely none) as wildcards, and then compares that to the stringification of 'sometime'. Is that what you wanted to do? If so, that is certainly a confusing way to accomplish it.

but there was no need to be so hostile about it!

I don't see where I could even be reasonably interpreted as "hostile" much less "so hostile". The closest I came to "hostile" was toward Oracle. Did you take that personally? Perhaps I should have been more like Dominus and instead said "You can't just make shit up, Retardo." At least that would've been rude. "Hostile" surely goes beyond "rude". I tried to find some examples of "hostile remarks" but every hit I checked just showed people being unwilling to even repeat them in quotes. I encourage you to not paint in your mind text-only remarks with such stark emotions so readily.

- tye

Comment on Re^5: DBIx::Simple and Oracle dates (stuff)

Replies are listed 'Best First'.
Re^6: DBIx::Simple and Oracle dates (stuff) by Argel (Prior) on Jun 16, 2010 at 00:05 UTC
Our master list is based on who is in what group on the CiscoSecure ACS appliances, because this is the real level of access users have. An audit script runs against that and updates the table I am hitting. So the only way for me to identify current users is to check the upate_timestamp field. As long as my script runs after the other auditing script then the string comparison is fine. And if they do not match up then my script will exit (well, I will probably have it email me a warning that there were no users found). With that said, it would probably make more sense to find any entries that update_timestamp is 24 hours old or less in instead of doing the string comparison. And this was supposed to be a quick and dirty script. Regarding hostile: The 'Because you can't just make stuff up?" paragraph. The "question" sets a pretty negative tone, and the rest of the paragraph reinforces it. It didn't help that it felt like you glossed over my post -- i.e. that the query works in SQL Developer. I mean, it worked, so I wasn't just "making stuff up". Elda Taluta; Sarks Sark; Ark Arks	[reply]
Re^7: DBIx::Simple and Oracle dates (junk) by tye (Sage) on Jun 16, 2010 at 01:50 UTC
I'm sorry that you don't appear to have understood that paragraph. I'm sorry that you took it as hostile. It wasn't meant as hostile. If you had managed to avoid interpreting it as hostile, then I believe you would have had more luck in understanding it. It didn't help that it felt like you glossed over my post -- i.e. that the query works in SQL Developer. Based on your responses, you appear to have only been glossing over my replies. But that is to be expected when one applies stark emotions to one's interpretation. I didn't respond to the post you mention above. I responded to a different post of yours. I responded mostly to just the following: Why isn't "like" appropriate? I'm only specif[ying] e.g. a date and leaving the time out, so it's not an exact match. That, in itself, demonstrates that you just "made up" something. The fact that you found a case where your made-up semantics appear to match observed behavior doesn't actually disprove that the semantics you posit are just made-up. Did you read a manual entry about "LIKE" that noted that it can be used to do "an [in]exact match" between date and/or datetime values (and without using '%')? If not, where did you get this feature idea? It is my assessment that you just made up those semantics. I stand by that assessment. I mean, it worked, so I wasn't just "making stuff up". "It appears to work" or "it works in the cases that I've tried" doesn't actually mean that it is doing what you think or what you meant it to do. Since the values that you were dealing with almost surely contained no '%' characters, then `LIKE` "working" likely just means that you ended up with two identical strings (`'foo' LIKE 'foo'` is true in SQL). Your assumption that "so it's not an exact match" was likely incorrect. My guess is that your datetime got converted to a date before the comparison was done. There was likely an exact match after type conversion took place. I say "likely" all over the place because I'm making educated guesses rather from afar. Had you researched what LIKE actually does for your particular database, you probably wouldn't have stuck with your made-up behavior idea. The reasons I said "made up" rather than something more mundane like noting that you appear to be or are likely mistaken are at least 1) Somebody had already taken the latter option (which still didn't appear to prompt you to examine or research your imagined behavior), 2) Your imagined behavior was quite at odds with the quite specific and simple behavior of LIKE (at least in the databases I am familiar with) and appears to have been prompted by little more than the English meaning of the word "like", 3) I found it mildly amusing. The reasons didn't include "I was trying to be hostile" nor even that I was feeling hostile. - tye	[reply] [d/l] [select]
Re^8: DBIx::Simple and Oracle dates (junk) by Argel (Prior) on Jun 16, 2010 at 18:19 UTC
My guess is that your datetime got converted to a date before the comparison was done. There was likely an exact match after type conversion took place. Yeah, I think you're right. Looks like SQL Developer truncating to just the date. The thing is it didn't feel like I was "making anything up" at the time because I knew the data had the date and time and my query was working in one place but not the other. I was incorrectly assuming SQL Develper was just truncating the results for display purposes. Time to track that setting down in SQL Developer. I still don't see how telling someone they are just making stuff up can be considered anything but rude. I appreciate the help, but next time please try leaving the extra "commentary" at home. Elda Taluta; Sarks Sark; Ark Arks	[reply]