Abort, Retry, Fail
-
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')
-
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_
-
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
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
-
I like that. We had a developer made some sort of import thing pipe delimited. That was fine and dandy until a user managed to enter a pipe in an address.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
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
Back when dinosaurs were young, I was at the University of Iowa Physics Research Center (now Van Allen Hall) working 3rd shift as a computer operator for 3 Univac 418's (Model I, Model II, Model III, pick your level of obsolescence even back then). One of my tasks was to create the papertape used to guide the radio observatory dish at North Liberty (NLRO) to track the the orbit of the Hawkeye I satellite for data collection. None of our systems had hard drives. Compilation of programs was performed by rewinding and reloading the compiler and loader from magnetic tape. S-L-O-W does not begin to express the glacier speed of this process. Made worse by the fact that the program had to be reloaded for each batch of directional data used to make each tape. As a self-taught programmer, this offended my sensibilities. I took to rewriting the program so it only needed to be loaded once for all the datasets. Turned out the program defined a block of zeros. When the data was read, it was stored, overwriting the zeros. The program started at the beginning of the block and read data until it hit a zero and then quit. I installed a loop to wipe the buffer and then tested the program. The first data tape matched the old program perfectly. I proceeded to run my modified program for the rest of the data. Needless to say, my program ran much faster and I found myself with time on my hands for the rest of my shift. The next day, one of the "system" programs was in the machine room. As I approached him, he snarled, "Stay away!" It seemed after the first tape guided the radio telescope to track the Hawkeye I satellite, the second tape had it careening all over the sky and an operator out there had to sit on a joystick all night long guiding it by hand, watching a signal strength meter. Turns out, my theory was correct, I just fell victim to the "off-by-one" bug. When I erased the buffer at the end of the program, I erased one word too many. So what you might think, it was at the end of the program. Well it turned out, that the program made use of a literal. The compiler stores literals at the end of the program. So I was wiping out a constant used in the orbital calculations. Once they found this bug, they used my version of the program thereafter. But it was the one instance I feared I would lose my job over something like that.
Psychosis at 10 Film at 11