Abort, Retry, Fail
-
5'd to compensate for the 1-voting tool.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Someone with a reasonably large rep is 1'ing.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre Have a bit more patience with newbies. Of course some of them act dumb -- they're often *students*, for heaven's sake. -- (Terry Pratchett, alt.fan.pratchett)
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Once deployed a system with a debug screen that displayed the stored data prior to a save, this wasnt pointed out until a good year later, I removed the code in the following release, next think we knew the business raise a critical fault log because this debug screen was not appearing and was vital to the business process!
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Not my most recent, but... A customer took some new EPROMs I sent him from his London office, to a Glasgow Telephone exchange for live testing. When he got there, he tried them, and couldn't find any of the new code functionality. He calls. I assume he has the previous version, so I blow some more latest version, while he flys down to Hampshire to get them. He dives in, collects the proms, and dives back to the airport (he had an "appointment" with one of his girlfriends in Glasgow that night). A few hours later he is back on the phone - same thing. Who hadn't taken the "if development machine" code check out of the production code? Oops. :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
-
Someone with a reasonably large rep is 1'ing.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre Have a bit more patience with newbies. Of course some of them act dumb -- they're often *students*, for heaven's sake. -- (Terry Pratchett, alt.fan.pratchett)
Yeah - I'm seeing a rash of -16's and -8's in my rep history. I remember someone saying once that people with a reasonably huigh rep wouldn't do such things, but I guess we've proven them wrong today.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
5'd to compensate for the 1-voting tool.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
-
John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
Actually, "tool" is a slang reference to the male reproductive organ, and thus, way more appropriate.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
John Simmons / outlaw programmer wrote:
the 1-voting t fool.
FTFY
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
-
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Tim Carmichael wrote:
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system.
:wtf: :wtf:
That's called seagull management (or sometimes pigeon management)... Fly in, flap your arms and squawk a lot, crap all over everything and fly out again... by _Damian S_
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
I used System.Security.Permissions.FileIOPermission in C# so I could check for file permission only to discover that Window 7 will still throw exceptions otherwise. Oh, wait, that is a rant.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
-
Tim Carmichael wrote:
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system.
:wtf: :wtf:
That's called seagull management (or sometimes pigeon management)... Fly in, flap your arms and squawk a lot, crap all over everything and fly out again... by _Damian S_
The developer that wrote the application used the web service provided by corporate. I don't blame him - he did what he was told. All was fine and good until corporate decided they wanted to make changes on the development server, then the problem came to light.
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
I rediscovered that dereferencing
NULLis bad karma.Software Zen:
delete this; -
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Actually had a similar SNAFU today. We are a Canadian retail giant (if you're Canadian, you can probably figure out who!) and last night we deployed a new version of one of our major applications that has hundreds of users within the company and across the country. However, the install package was created with the wrong security INI file. Instead of pointing to our Production security server, it was pointing to the Development server. :omg: Obviously 90% of our users are NOT configured on the Development server, so hilarity (read: CHAOS!) ensued. Unfortunately, since I'm currently the only developer with access to create the correct install package, the problem wasn't solved until around 9:45 after I got to work. The package needed to be distributed to local SMS servers country-wide by another department, so another hour or so was required until we could provide a new install package to the users. All in all, users were deprived of that application from the opening of the availability window at 7AM until around 11AM. Gonna look really good on our system statistics next week. :(( Needless to say, my manager was not amused. -EM
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Hmm, I just thought of another one involving me ...... maybe I'm not actually cut out for this job???? :laugh: In my first job I was working on an ERP system called Triton (anyone else know it? it later became known as BAAN), and we needed to correct a label printing issue for one of our clients, a furniture manufacturer. We needed to test on the specific printer at the client site to make sure the spacing requirements were met, so we were told to substitute one of the text fields on the label with my name and the users would know that it was us and to notify how it went. Well, after we put the correction in production my buddy, a Consultant at the client, came by and told me that we'd forgotten to remove my name from the code and that quite a few shipments had gone out with the my name on the shipping labels, and some of the client's customers were inquiring as to who this "EM" guy was! :-O My buddy still gives me grief over that one! -EM
-
Not most recent - but a fun one nonetheless. Chap was tasked with changing the Invoice print to ask for a number of copies to be printed - simple task, knocked it over in an hour, tested, and distributed by the ned of the week. One Happy Customer. Until a week later. After refilling the printer with (from memory) four boxes of paper, it was still printing invoices. when they (finally!) checked, they noticed the same invoice was printing over and over again... "Imposiible!" quoth the programmer responsible for the change. Look...
Do
PrintInvoice();
CopyCount--;
Until CopyCount == 0;Turns out the user had decided she didn't actually want to print the invoices at all - so entered zero for the number of copies!
MVVM# - See how I did MVVM my way ___________________________________________ .\\axxx (That's an 'M')
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Was working on a customer's (test) Sql Server d/b the other week, using SSMS. I took the d/b offline ready to copy/paste the .MDF file in preparation for cloning the d/b to a live one. But turns out my user ID had access to ONLY that d/b; so once offlined, I now had no access to ANYTHING in SSMS - including the ability to bring "my" database back online. We did eventually track down the sa user logon, but it took a while to do so... WHY does SSMS allow you to do that??! Derek TP
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
No so much an abort, retry, fail but an expensive case of pointing to the wrong environment... Around a year ago I worked with a client taking credit card payments online. We sent CC data to a 3rd party payment provider who communicated with the banks. As a startup operation, there was no cash flow to begin with and it was around 5 weeks before we expected the first actual payments from the bank. Week 5 came and went with no money, and after some investigations it turned out our payment provider had been sending the CC data to the bank's TEST system all that time. :omg: Several tens of thousands of transactions, running to several hundred thousand dollars. The bank had never noticed the very high volume of "test" transactions (or had noticed and not remarked). The 3rd party payment provider spent several weeks manually contacting customers to try and recover some of the losses.
-
Last week, I was told that an application we are using to send data to corporate on a daily basis was, in fact, sending the data to the development system. The development system was then routing the data to the production system. Looking at the code, I discovered the system has been in place for a couple of years and the previous developer had been told to send the data to the development server. Fine so far. I set about changing the destination server and tested the application from my PC. Again, fine so far. Deployed the application to the primary user. This morning, I had a voice mail saying there was a break point and the application would not continue. Odd... breakpoints should be for debugging only. Discovered I had, in fact, left a 'stop' statement in place while testing; the stop statement was there because the code was looping through years of files and I only wanted a file from this year. Leaving the stop statement was my abort, retry, fail moment... glad it was easy to fix and did not affect production. What is your most recent abort, retry, fail moment? Tim
Also 5'd for the low voting...This type of thing has happened to everyone, only most would not admit it. I have learned to set breakpoints on print statements and no longer use a stop for debugging. As for my moment, I deployed numberous updates for our distributed software and modules that crashed on client systems with a rather generic 430 Class/Automation error. But of course I tested them and they worked fine...but I did install SP1 for Win7 last week on my main development workstation. When I tested the executables on my laptop (Win7 without SP1) they failed, but the code worked just fine. I quickly recompiled all the affected files on the laptop and redeployed. It turns out that Win7 SP1 replaces the ADO libraries that are incompatible with down level operating systems, or anything but 7SP1. If you compile executables or dll's on a Win7 workstation with SP1 installed, and you use the ADO libraries, be aware that they might not run on other systems.
"Go forth into the source" - Neal Morse
