Today I did the impossible.
-
honey the codewitch wrote:
Today I did the impossible used my years of experience which allowed me to make some educated guesses about a problem, one of those guesses was accurate, and prompted a change that help fix the problem.
For some reason I believe this is more probable. :)
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
You can't buy experience.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
Down memory lane we go ... In my case we were using a GIS-system that included encryption of username and password in connection strings for SQL Server ... They had implemented a variant of Ceasar chipher of their own design ... Unfortunately 'n' and 'm' ended up being replaced with a zero-width-character in Windows Latin1 ... and having that at the end of the connection string turned out to be a rather bad idea as the full string seldom was marked in copy-n-paste :sigh: Why 'n'/'m' was such a bad choice? Their default username was "admin" and the password was "Solen" (besides, passwords was case-ignorant). and ... their system assumed that "USER ID" and "PASSWORD" allways was encrypted ... and up we pops again :-)