• (cs) in reply to Tony Toews

    [quote] Although the real answer is generating the invoices in such a way that they are one continuous print job.[/quote] As for sending them all in one print job...is there a way to print Access reports that way? [/quote]

    Exceedingly easy. I'm quite puzzled as to why they didn't do that.

    Tony Toews, Microsoft Access MVP[/quote]

  • Buddy (unregistered) in reply to m03
    m03:
    Was AppActivate not available in VBA like it was in VBScript? Assuming so, an AppActivate before every keystroke, combined with only sending one keystroke at a time would have solved that problem. I could be remembering VBAs features incorrectly though.

    It wasn't a pretty way to automate things, but it sort of worked (atleast in VBScript).

    Yes, I remember we tried that or equivalent. You still needed a pause after AppActivate, like five seconds (!), for the application to process, so it actually made it worse. These were really crappy machines. Nobody wanted them so we repurposed them as report generator "robots".

  • DWalker (unregistered)

    Yes, depending on the OS that's running the print queues, when the printer is first set up, there's generally a choice to print everything FIFO or smallest first, or some weighted variation.

    Smallest first is a useful choice sometimes, but can have unintended consequences if people don't realize the choice is there.

  • John Reese (unregistered) in reply to Tony Toews

    [quote user="Tony Toews"][quote] Although the real answer is generating the invoices in such a way that they are one continuous print job.[/quote] As for sending them all in one print job...is there a way to print Access reports that way? [/quote]

    Exceedingly easy. I'm quite puzzled as to why they didn't do that.

    Tony Toews, Microsoft Access MVP[/quote]

    Each page of each invoice was a separate report instance. Some of the customers had extra reports thrown into the mix, based on the type of customer.

    The process was:

    1. Go through the list of customers
    2. Find out which reports are needed for each customer
    3. Print the reports in the correct order for that customer
    4. Repeat until done

    So this can easily be sent to the printer in a single job, using Access 97?

  • Buddy (unregistered) in reply to DWalker
    DWalker:
    Yes, depending on the OS that's running the print queues, when the printer is first set up, there's generally a choice to print everything FIFO or smallest first, or some weighted variation.

    Smallest first is a useful choice sometimes, but can have unintended consequences if people don't realize the choice is there.

    We didn't tell the regular staff about the choices. Only development knew that you could set print jobs to higher priority to get pushed ahead of the queue. It gave me a bit of satisfaction to see dozens of huge jobs pending, and have my little listing job right behind the one actively printing.

    While some might call me some choice words for not disclosing this feature, from experience we knew it would be abused with the eventual outcome that everyone would set their jobs to 99 priority as a default.

  • Mark (unregistered) in reply to wee
    wee:
    kastein:
    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    What kind of nitwit uses Access and VB in the first place? I mean, if you're going to start peeling the nitwit onion, you'll have to peel it all the way down to Redmond...

    Those of us with more sense and maturity than you know that sometimes you can't change the environment. You work with what the business is using. If that's Access, then that's what you use.

    That's not to say of course that you shouldn't persuade management to use better tools.

    Now, as for the initial usage of Access/VBA for these invoices. My guess is that at the time this was a much smaller scale operation. They were generating invoices manually, maybe with Excel. Then along came the aforementioned nitwit and he built an invoicing system. It was shitty, but the business didn't know any better. As time went on, the limitations of Version 1.0 began surfacing more and more.

    That's how it happens in the real world.

  • Jamie Edwards (unregistered) in reply to John Reese
    John Reese:
    IIRC, sleep() was the first thing I tried. The question is...how long do you sleep? Is a minute long enough? Five minutes? Thirty minutes?

    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    So, I put the message box in place, and instructed the accounting clerks to hit "OK" as soon as the printer stopped printing.

    I agree that this is a suboptimal fix. Can you suggest an optimal fix, one implemented entirely in VBA code?

    As for testing...any of us would like to think that our testing of this process would, of course, naturally include going through each of the hundreds of invoices by hand, one by one, to make sure they are all in order.

    I mean, we are ALL that thorough in our testing, aren't we? And we would follow it through all the way to the end, JUST IN CASE the first 120 were fine, but the next fifteen were not? Even when we have no reason to believe the invoices will print out of order, since they had never done this before?

    SURE we would.

    15 second google search revealed code that will allow you to pull a print queue status using WMI:

    strComputer = "." Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\" & strComputer & "\root\cimv2") Set colPrintQueues = objWMIService.ExecQuery _ ("Select * from Win32_PerfFormattedData_Spooler_PrintQueue Where " & _ "Name <> '_Total'") For Each objPrintQueue in colPrintQueues Wscript.Echo "Name: " & objPrintQueue.Name Wscript.Echo "Current jobs: " & objPrintQueue.Jobs Next

    All you would need to do is poll the print queue every 5 seconds or so, once it reaches zero, then start sending jobs again.

  • John Reese (unregistered) in reply to Mark
    Mark:
    wee:
    kastein:
    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    What kind of nitwit uses Access and VB in the first place? I mean, if you're going to start peeling the nitwit onion, you'll have to peel it all the way down to Redmond...

    Those of us with more sense and maturity than you know that sometimes you can't change the environment. You work with what the business is using. If that's Access, then that's what you use.

    That's not to say of course that you shouldn't persuade management to use better tools.

    Now, as for the initial usage of Access/VBA for these invoices. My guess is that at the time this was a much smaller scale operation. They were generating invoices manually, maybe with Excel. Then along came the aforementioned nitwit and he built an invoicing system. It was shitty, but the business didn't know any better. As time went on, the limitations of Version 1.0 began surfacing more and more.

    That's how it happens in the real world.

    And that's exactly how it happened in this case. When I started there, we had just begun to sign up residential customers, and took that opportunity to design a proper new system from the ground up. However, our commercial customers were firmly entrenched in the old system, and couldn't be pried loose without breaking everything.

    And need I mention that the commercial customers were far more lucrative? That creaky old code was treated with kid gloves to avoid a disastrous interruption of service which would have put us out of business in short order.

  • Jay (unregistered) in reply to John Reese
    John Reese:
    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    But this would be easy! Just do an exec call to bring up the printer queue window. FindWindow to get a handle to it. Then do SendKey's to send the commands to make it display the list of print jobs. Finally, GetWindowText to read the list of print jobs. Parse this list. When it is empty or at least below some threshold, you can fire off the next print.

  • Real-modo (unregistered) in reply to John Reese
    John Reese:

    ... using Access 97?

    Cripes! If the management applies this kind of investment logic for mission-critical systems, it's entirely reasonable to blame the network first up. It must have been wet string and tin cans. I wonder how they produced their product? Using bicycle dynamos?
  • Real-modo (unregistered)

    ... congratulations on an excellent front-ahead design fix, by the way.

  • (cs) in reply to John Reese
    John Reese:
    Mark:
    wee:
    kastein:
    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    What kind of nitwit uses Access and VB in the first place? I mean, if you're going to start peeling the nitwit onion, you'll have to peel it all the way down to Redmond...

    Those of us with more sense and maturity than you know that sometimes you can't change the environment. You work with what the business is using. If that's Access, then that's what you use.

    That's not to say of course that you shouldn't persuade management to use better tools.

    Now, as for the initial usage of Access/VBA for these invoices. My guess is that at the time this was a much smaller scale operation. They were generating invoices manually, maybe with Excel. Then along came the aforementioned nitwit and he built an invoicing system. It was shitty, but the business didn't know any better. As time went on, the limitations of Version 1.0 began surfacing more and more.

    That's how it happens in the real world.

    And that's exactly how it happened in this case. When I started there, we had just begun to sign up residential customers, and took that opportunity to design a proper new system from the ground up. However, our commercial customers were firmly entrenched in the old system, and couldn't be pried loose without breaking everything.

    And need I mention that the commercial customers were far more lucrative? That creaky old code was treated with kid gloves to avoid a disastrous interruption of service which would have put us out of business in short order.

    May I be frist to say "Don't use Access for this?"

    Don't use Access for this. Use Access where appropriate. I'm struggling ... but, not for this.

    Can I just please flame inappropriate tools?

    John Reese:
    And need I mention that the commercial customers were far more lucrative? That creaky old code was treated with kid gloves to avoid a disastrous interruption of service which would have put us out of business in short order.
    Yes, you may. I'm a contractor. I have limited time to do anything, and somebody has fucked up the entire environment before I got there.

    Day 1: "OK, show me the source code. It's in Access/ASP/X-Framework/Blub is it? Gimme a day to check it out."

    Day 2: "OK. Tell me the two or three things that the client is screaming about."

    Day 3: "I think I've got a possible fix for two of those three things. Which one is the most important?"

    Days 4-7: Hell. I don't want to deal with this crap, but even a slight improvement will avoid things like print queues that don't know how to queue.

    Day 8: (Boss) "Well, that seems to have worked well. Good job! Any chance you can ... I just read this book, and I think the word is 'refactor' ... our Access system into C++.Net, which is basically the same thing? Or maybe you could use Ruby on Rails?

    Day 8.5: "Bartender. Gimme a shot of your best single malt. With a quintuple beer back."

    Look if it starts with Access, it's doomed. It's not doomed because Access is bad, or even because Access is naughty. It's not even doomed because Access programmers are inherently bad, and naughty, and moronic people.

    It's just moths to a flame. Have you ever wondered why moths are attracted to something like a flame, which is inherently fatal?

    Well now. Have you ever seen a financial or product manager try to defend the use of Access?

  • (cs) in reply to Jay
    Jay:
    John Reese:
    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    But this would be easy! Just do an exec call to bring up the printer queue window. FindWindow to get a handle to it. Then do SendKey's to send the commands to make it display the list of print jobs. Finally, GetWindowText to read the list of print jobs. Parse this list. When it is empty or at least below some threshold, you can fire off the next print.

    No, don't be silly, that'll never work! ...

    ... GetWindowText will only return you the title when you're talking about an explorer pane view like that.

    What you really need to do is SendKey Alt+PrtSc to take a screensnap, then send more keys to fire up MsPaint, paste the image in, and save it to a temprorary file somewhere. Then you can OCR the information about the print queue back out of it. And with the added advantage that by the time you've done all that, the queue will be shorter anyway!

  • 50% Opacity (unregistered) in reply to DaveK
    DaveK:
    What you *really* need to do is SendKey Alt+PrtSc to take a screensnap, then send more keys to fire up MsPaint, paste the image in, and save it to a temprorary file somewhere. *Then* you can OCR the information...
    No, that won't work, because you would need to print out the screenshot frist to put it on a wooden table, but since the print queue is blocked...
  • David (unregistered) in reply to Buddy

    [quote user="Buddy"]Oh yeah, been there, done that.

    The worst was the dreaded Excel hack for printing to file. [quote]

    I worked on an app that wrote Excel reports using DDE.

    You could sit back and watch as hundreds of sheets, tables and graphs were generated as if by some poltergeist.

    Generally it would work OK in the background, only consuming 50% or so of the CPU. But god save you if you ever tried to open another excel workbook while the process ran.

  • Hmm (unregistered)
    Well now. Have you ever seen a financial or product manager try to defend the use of Access?

    Of course. I had to deal with Access 97 back in .. 1997. I squeezed every bit of water from that rock. The mdb size exceeded .99gb which was the limit so I had to split up the tables into separate mdb's. I had more users than access could handle so I had to have a read/write version of the tables and a read only version. I had windows replicate the read/write version to the read only files every night. This could have conceivably gone on until the read / write users exceeded the hard connection limit or the biggest table exceeded .99gb.

    I begged and pleaded to get my boss to let me port it to SQL 6.5/7.0 and VB but he just wouldn't have it. My boss was the CFO. Luckily I got an Oracle contracting gig shortly after and have never looked back.

    Businesses that don't specifically sell technology just want it to work and they want it to be cheap. Thinking about it, that's a pretty good strategy. Unfortunately it sometimes blinds people to be reactive instead of proactive when they really need to be. In technology, when you're reactive, it's often too late.

  • (cs) in reply to John Reese
    John Reese:
    Each page of each invoice was a separate report instance. Some of the customers had extra reports thrown into the mix, based on the type of customer.

    The process was:

    1. Go through the list of customers
    2. Find out which reports are needed for each customer
    3. Print the reports in the correct order for that customer
    4. Repeat until done

    So this can easily be sent to the printer in a single job, using Access 97?

    Ah, now I get it. No, that's not at all easy within Access. You could try using subreports, reports embedded within reports, but they don't do all that well when multiple pages are involved.

    What I'd suggest is using the Lebans PDF printer DLLs to produce individual PDF files. Then use that utility to combine the PDF files and then print the file. See http://www.lebans.com/reporttopdf.htm for more details. And it works under A97 as well although you have to read the readme file.

    That would likely take an hour or three of VBA coding to get running smoothly.

    Then I'd just ask the customer if they wanted the files emailed to them.

    I have clients in the oilpatch in remote sites filling in time and rate data daily while at the oil rig site for invoicing. The app automatically creates the PDF files and emails the consultant at the rig site via cell phone data card. The app also emails the PDF files to the bookkeeper at the office so they can do the followup.

    Tony Toews, Microsoft Access MVP

  • (cs) in reply to pink_fairy

    [quote user="pink_fairy]Look if it starts with Access, it's doomed. It's not doomed because Access is bad, or even because Access is naughty. It's not even doomed because Access programmers are inherently bad, and naughty, and moronic people.[/quote]

    Absolute rubbish. Access is an excellent tool for creating applications. It has it's limitations of course.

    The biggest problem most IT and developers have with it is that inexperienced folks create poor to mediocre apps with it. But hey, at least they're not using Excel.

    Tony Toews, Microsoft Access MVP

  • (cs) in reply to Hmm

    [quote user="Hmm] I begged and pleaded to get my boss to let me port it to SQL 6.5/7.0 and VB but he just wouldn't have it. [/quote]

    I can understand upsizing the data to SQL Server as that makes a lot of sense in that situation. But why not leave the app in Access? What advantage would you get with VB?

    Tony Toews, Microsoft Access MVP

  • Hmm (unregistered) in reply to Tony Toews
    Tony Toews:
    I can understand upsizing the data to SQL Server as that makes a lot of sense in that situation. But why not leave the app in Access? What advantage would you get with VB?

    Tony Toews, Microsoft Access MVP

    Honestly, because I didn't know any better at the time and I wanted to learn VB. All the periodicals were touting VB as THE pair for SQL Server. In hindsight, VB wasn't that much better than Access. It was interpreted, which ran a lot slower 12 years ago than it does today. My boss only let me buy the bargain basement workstations. It wasn't fully OO and most of the components you could get for VB, you could get for Access. Plus, I would have to either use Crystal Reports (which still sucks compared to Access) or have Access do the reports. I think you also had to have an Access license to run an Access app, but I could be wrong.

    If I were to do it again, assuming the same year, I would have chosen Delphi connecting to SQL Server. Delphi because it was a very nice OO, compiled language that was very innovative (the guy that wrote it wrote C#). The development environment also ran circles around VS at the time. SQL Server because it would probably have ported better than Oracle. Oracle's licensing rates were about double of SQL Server's back then too. SQL Server 7 was definitely easier to administer at the time as well. Unfortunately I didn't discover Delphi until my Oracle consulting gig.

  • (cs)

    Your modem has downloaded 100 MB. Press OK to continue.

  • db (unregistered) in reply to m0ffx

    The user then decides they would like it to print quickly so they set it to 1 second :(

  • David W. Fenton (unregistered) in reply to pink_fairy
    pink_fairy:
    May I be frist to say "Don't use Access for this?"

    Are you people totally nuts? This is a perfect application for an Access front end -- the Access report writer is as good as it gets. The issues with queuing are completely resolvable, as Tony Toews explains.

    Sturgeon's Law applies everywhere.

    -- David W. Fenton http://dfenton.com/DFA/

  • Aloha Dano (unregistered)

    We have a similar problem printing cheques from our AIX-based banking system, to dot-matrix printers, with a print server attached. (each branch has a network-enabled cheque printer.)

    The cheques are pre-printed tractor feed with the cheque number printed on each cheque with the special font/ink.

    AIX supports either HP Jetdirect, or BSD/System V/lpd printing,and our D-Link parallel print servers supposedly support that too. The problem is, we send maybe 10-20 cheques at once each morning - each one's a separate job. In Jetdirect mode, the D-Links often ignore the first job sent, so cheque 100 gets the details from cheque 101 printed on it, etc.

    Because the jobs are so small - eg maybe 100 bytes the D-Links seem to just ignore the first job that comes in, sometimes. Printing a larger job works fine though.

    In LPD mode, the print servers work flawlessly,but don't seem to respond to AIX'es status polling in a format AIX can understand.

    After a while AIX just assumes the printer is offline and brings down the print queue, so any printed cheques just get banked up in the queue.

    Our solution? we've wound out the AIX LPD timeout to about 1 hour, and run a cron job that manually brings up any cheque print queue that's been downed.

    Yes, we're looking at alternative printer servers. Netgear ones are even worse (dodgy power suppliesm the also lock up regularly), HP's are insanely expensive and also lock up occasionally, and you can't print raw LPD jobs to a windows print queue nicely without windows imposing some formatting.)

  • Herby (unregistered)

    Queues are weird things. Even more so if users have anything to do with it. One time we allowed priorities to be from 1-15, and everyone chose 15, and you couldn't get anything "high priority" manually. What we ended up doing was limiting the users to only a priority of 1. We could then override as we needed, and everyone was happy.

    Then again any "queue" that alters the position of the print job on its own is REALLY screwy!

  • Luke (unregistered)

    We started with Windows 3.11 on Novell Netware. We stopped the print process every 20 reports (about 200 pages) because the process crashed when the queue got full. You waited until the printer stopped printing, then resumed the job.

    Gradually everything got better. The limit moved to 50, 75 The current process (Windows XP/ Server 2003) does a batch of 200 (about 1500 pages) without any intervention other than refilling the alternating paper trays.

  • (cs) in reply to Tony Toews
    Tony Toews:
    pink_fairy:
    Look if it starts with Access, it's doomed. It's not doomed because Access is bad, or even because Access is naughty. It's not even doomed because Access programmers are inherently bad, and naughty, and moronic people.

    Absolute rubbish. Access is an excellent tool for creating applications. It has it's limitations of course.

    Right. That's like saying "VSS is an excellent tool for revision management. It corrupts your data of course."

    Or to put it another way, claiming that "VSS is an excellent tool for revision management. It has it's limitations of course." would be just the same as saying "Access is an excellent tool for creating applications. It corrupts your data, of course."

    Access is a great database for one user on a non-networked workstation, just like VSS is a great SCM for one user on a non-networked workstation. It is when you introduce multiple users and a network full of servers that their "limitations" begin to seem like crippling defects that render them fundamentally unfit for purpose. Most people would consider simultaneous multi-user access to be of the essence of a DB or SCM, not a nice-to-have extra.

    Anyway, I don't see why we should take advice from someone who can't even balance his opening and closing quote tags!

  • (cs) in reply to DaveK
    DaveK:
    Tony Toews:
    pink_fairy:
    Look if it starts with Access, it's doomed. It's not doomed because Access is bad, or even because Access is naughty. It's not even doomed because Access programmers are inherently bad, and naughty, and moronic people.

    Absolute rubbish. Access is an excellent tool for creating applications. It has it's limitations of course.

    Right. That's like saying "VSS is an excellent tool for revision management. It corrupts your data of course."

    Or to put it another way, claiming that "VSS is an excellent tool for revision management. It has it's limitations of course." would be just the same as saying "Access is an excellent tool for creating applications. It corrupts your data, of course."

    Access is a great database for one user on a non-networked workstation, just like VSS is a great SCM for one user on a non-networked workstation. It is when you introduce multiple users and a network full of servers that their "limitations" begin to seem like crippling defects that render them fundamentally unfit for purpose. Most people would consider simultaneous multi-user access to be of the essence of a DB or SCM, not a nice-to-have extra.

    Anyway, I don't see why we should take advice from someone who can't even balance his opening and closing quote tags!

    Hey man, don't go knocking the MVP!

    For me, the WTF is releasing to production without having done a full run of ALL the reports on PROD (or near PROD) data. It would have raised your issue earlier but also a full run is ALWAYS required so that you can:

    There's no freaking way - I KNOW that I tested for this!

    Well no, clearly you did not, you did not;

    a) Check the WHOLE process

    nor did you

    b) Ensure it stops gracefully, connections are closed, memory released, that sort of stuff, you know like "the basics" of testing.

    I would also set up some deliberate test failures, such as:

    a) printer goes offline. b) printer runs out of paper/toner. c) someone reboots the pc/powerloss - can it pick up where it left off, or do you have to restart the whole process.

    Once again a failure due to inadequate testing. And for heaven's sake will just ONE developer posting management WTFs here grow a pair and start standing up for their principles! "Management" do actually understand what's going on, they just seem to like bullying people. And the reason they get away with it is only because people LET them!

    Sounds like another hack/slash merchant with no eye for detail to me. Thankfully there are plenty of them about which keeps the competition for jobs DOWN and my wages UP.

    :)

  • Sid2K7 (unregistered)

    Well, if there is such a huge increase in invoices to be printed, they should have gotten a letter printer in the first place. The variety that prints and puts the letter in an envelope right away. They are FAST beasts. I know one that prints faster than Word can deliver it's pages for a serial letter. 120 ppm or something like that. I've never even seen a print-job in the queue. Has some 512 MB of RAM. Beast, like I said.

  • Uhh (unregistered) in reply to John Reese
    John Reese:
    IIRC, sleep() was the first thing I tried. The question is...how long do you sleep? Is a minute long enough? Five minutes? Thirty minutes?

    What I needed was some way to tell when the printer had finished spitting out invoices. There is no Windows API for that.

    So, I put the message box in place, and instructed the accounting clerks to hit "OK" as soon as the printer stopped printing.

    I agree that this is a suboptimal fix. Can you suggest an optimal fix, one implemented entirely in VBA code?

    As for testing...any of us would like to think that our testing of this process would, of course, naturally include going through each of the hundreds of invoices by hand, one by one, to make sure they are all in order.

    I mean, we are ALL that thorough in our testing, aren't we? And we would follow it through all the way to the end, JUST IN CASE the first 120 were fine, but the next fifteen were not? Even when we have no reason to believe the invoices will print out of order, since they had never done this before?

    SURE we would.

    Depending on the organization it may be the responsibility of developers or the end-users, but, actually, YES, the simplest possible acceptance testing before going to production would involve the users processing a whole batch of invoices with the new system and seeing if the results are ok to them - and they DID find out immediately that the results are not ok...

    This was just a simple 'try-it-out', not even something that should be called testing.

  • Most Valued Poster (unregistered) in reply to DaveK
    DaveK:
    Anyway, I don't see why we should take advice from someone who can't even balance his opening and closing quote tags!
    Hush your mouth! He's an MVP - I bet he's got a certificate and everything.
  • Warren (unregistered)
    Original article:
    The only thing missing was the duct tape.

    Duct tape improves everything and is a professional tool. Don't diss the tape, man.

  • Bernie (unregistered) in reply to Noob
    Noob:
    kastein:
    This comment is first. It cut ahead in the queue.

    my god, sendkeys? what kind of halfwit uses that hack on a multitasking system?

    used hack^H^H^H^H send keys multiple times, I have.

    How many times do I need to tell you, Yoda, that using the name "Noob" does not hide your identity?

  • Addison (unregistered)

    Let me be the first to say that the developer did a decent job with the message box thing. It was obviously a terrible, terrible project to work on. I don't think that at that point anyone would have had the motivation to put more than a simple textbox in as a quick fix.

    In the developer's world there is only one question with a relevant answer- does it do what it's supposed to? If it does than ANY extra time spent is a waste of time.

  • John Reese (unregistered) in reply to Uhh
    Uhh:
    Depending on the organization it may be the responsibility of developers or the end-users, but, actually, YES, the simplest possible acceptance testing before going to production would involve the users processing a whole batch of invoices with the new system and seeing if the results are ok to them - and they DID find out immediately that the results are not ok...

    This was just a simple 'try-it-out', not even something that should be called testing.

    Well, at this organization, users were not involved in testing. This was something I fought long and hard about, because a person who has been using the system for years could spot mistakes much faster than a developer who just walked in off the street. I was told the users didn't have time for such nonsense.

  • John Reese (unregistered) in reply to Mr B
    Mr B:
    For me, the WTF is releasing to production without having done a full run of ALL the reports on PROD (or near PROD) data. It would have raised your issue earlier but also a full run is ALWAYS required so that you can:
    There's no freaking way - I KNOW that I tested for this!

    Well no, clearly you did not, you did not;

    a) Check the WHOLE process

    nor did you

    b) Ensure it stops gracefully, connections are closed, memory released, that sort of stuff, you know like "the basics" of testing.

    I would also set up some deliberate test failures, such as:

    a) printer goes offline. b) printer runs out of paper/toner. c) someone reboots the pc/powerloss - can it pick up where it left off, or do you have to restart the whole process.

    Once again a failure due to inadequate testing.

    :)

    Sheesh. If I had known my actions of six years ago were going to be subjected to such an excruciating vivisection, I would never have submitted the story.

  • John Reese (unregistered) in reply to Tony Toews
    Tony Toews:
    Absolute rubbish. Access is an excellent tool for creating applications. It has it's limitations of course.

    The biggest problem most IT and developers have with it is that inexperienced folks create poor to mediocre apps with it. But hey, at least they're not using Excel.

    Tony Toews, Microsoft Access MVP

    Case in point: Our operations people all knew Access really well. Not enough to be useful, but enough to do serious damage.

    One recurring problem we had was that the SQL database would lock up at a crucial point each morning when we were trying to purchase natural gas for the day's usage. I traced the problem to a single Access database used by the operations manager. The main form he was using was apparently corrupted, and it was putting a latch on the table that was locking out all the users. Since this was purely a menu form, with no data controls, I told him there was really no point in it having a connection to this table. He disagreed, and refused to let me touch his database.

    I waited for his day off, then made the change.

    On another ocassion, someone decided to make a copy of a critical table, then use this copy to do some sort of project that involved deleting and altering much of the data.

    It was -- you guessed it -- a copy of a LINKED table, not an actual table, so the production data was ruined.

  • BBT (unregistered) in reply to 50% Opacity
    50% Opacity:
    DaveK:
    What you *really* need to do is SendKey Alt+PrtSc to take a screensnap, then send more keys to fire up MsPaint, paste the image in, and save it to a temprorary file somewhere. *Then* you can OCR the information...
    No, that won't work, because you would need to print out the screenshot frist to put it on a wooden table, but since the print queue is blocked...

    But that's the beauty of it. The print queue bug allows your wooden table job to bypass the 100 in queue.

  • Anonymous (unregistered)

    I WTF'ed as soon as I saw SendKeys. Can't get much worse than SendKeys in... well, in any application at all ever.

  • (cs)
    Sheesh. If I had known my actions of six years ago were going to be subjected to such an excruciating vivisection, I would never have submitted the story.

    Well, this site ain't called The Daily Aww Poor Baby.

    If it was six years ago and you're a better developer now, you should be able to look back and laugh without so much emotional attachment. Of course if it was six years ago and you're still doing things the same way you did back then, well... it's about time for a wake-up call.

    You can do better. If you're not... why not?

  • Hmm (unregistered) in reply to John Reese
    John Reese:
    Sheesh. If I had known my actions of six years ago were going to be subjected to such an excruciating vivisection, I would never have submitted the story.

    Ah don't sweat it dude. Many of the people seem use these forums to boost their overinflated egos. They get a few years in the industry and think they know everything. They wouldn't dare post their worst code for scrutinization.

    I've done plenty of things in my career that, looking back, I should have done differently. Hey, that's how you learn and improve. If you aren't constantly improving, you need to move on, or get out of the biz.

    I think a huge milestone in any developer's career is if they have successfully lead a project, lasting at least a year, from start to finish, and made the deadline and budget. I'm talking the full gamut: requirements gathering, project planning, architecture (database, middle tier and client), implementation, testing and maintenance rollout all need to be handled. Until someone has done that, they don't have enough experience to be arrogant.

  • (cs) in reply to John Reese
    Sheesh. If I had known my actions of six years ago were going to be subjected to such an excruciating vivisection, I would never have submitted the story.

    You're not a regular then huh?

    :)

    It wasn't the story itself, but more your attitude to testing your work which came through via your subsequent comments here.

    You claim it was tested when it wasn't. You also still seem to think that performing exhaustive testing isn't within the domain of the developer, or somehow a waste of time (why bother checking them all? What a waste of time!).

    That's why you got (and probably still get) shouted at, and I don't. I made the mistake ONCE (in 1990) of releasing something that wasn't tested as much as humanly possible - or if it is released, it's with the proviso that I wasn't happy it was being released untested - and learned very quickly not to do the same again. It seems that you haven't learned anything from your failure to do adequate testing and it sounds like you'd test it again in exactly the same way...or is that wrong and I've misunderstood your comments?

  • IByte (unregistered) in reply to Pedantic
    Pedantic:
    by end cusotmer.
    HAHAHA. I found a typo in the article![...]
    On a related note, why is Wiktionary the only on-line dictionary that lists "painstakenly" as a valid alternative for "painstakingly"?
  • (cs) in reply to Hmm
    Hmm:
    John Reese:
    Sheesh. If I had known my actions of six years ago were going to be subjected to such an excruciating vivisection, I would never have submitted the story.

    Ah don't sweat it dude. Many of the people seem use these forums to boost their overinflated egos. They get a few years in the industry and think they know everything. They wouldn't dare post their worst code for scrutinization.

    I've done plenty of things in my career that, looking back, I should have done differently. Hey, that's how you learn and improve. If you aren't constantly improving, you need to move on, or get out of the biz.

    I think a huge milestone in any developer's career is if they have successfully lead a project, lasting at least a year, from start to finish, and made the deadline and budget. I'm talking the full gamut: requirements gathering, project planning, architecture (database, middle tier and client), implementation, testing and maintenance rollout all need to be handled. Until someone has done that, they don't have enough experience to be arrogant.

    Au contraire, I'd be quite happy to post my code - I have an extensive collection of god-awful code that I've written over the years. Hell I look at code I wrote last week and can see new/different ways to do it! But I realise that this is my shortcoming, and not anyone else's.

    Nope, this WTF isn't about the code, it's about the attitudes of developers and somehow making out that a combination of software, printer drivers and management were to blame, rather than a developers unwillingness to properly test their work. Just think...just one proper test run would have highlighted this issue...which is really the VERY LEAST testing that should have been done, nevermind the other negative tests I mentioned previously...

  • (cs)

    It's simple. John Reese found how to prevent the Rise of the Machines... with a dialog box!

  • (cs) in reply to Mr B
    Mr B:
    Nope, this WTF isn't about the code, it's about the attitudes of developers and somehow making out that a combination of software, printer drivers and management were to blame, rather than a developers unwillingness to properly test their work. Just think...just one proper test run would have highlighted this issue...which is really the VERY LEAST testing that should have been done, nevermind the other negative tests I mentioned previously...

    Indeed, developers are the first Testers on the scene. The QA department (if you have one) is there for the tedious bits, some unlucky pond scum of the IT world gets the test case "Print 10,000 invoinces and ensure they are printed in the correct order". If you don't have a QA department, guess who's the unlucky pond scum now? I'll give you a hint: It shouldn't be the end user.

  • Jay (unregistered) in reply to DaveK
    DaveK:
    Jay:
    But this would be easy! Just do an exec call to bring up the printer queue window. FindWindow to get a handle to it. Then do SendKey's to send the commands to make it display the list of print jobs. Finally, GetWindowText to read the list of print jobs. Parse this list. When it is empty or at least below some threshold, you can fire off the next print.
    No, don't be silly, that'll never work! ...

    ... GetWindowText will only return you the title when you're talking about an explorer pane view like that.

    What you really need to do is SendKey Alt+PrtSc to take a screensnap, then send more keys to fire up MsPaint, paste the image in, and save it to a temprorary file somewhere. Then you can OCR the information about the print queue back out of it. And with the added advantage that by the time you've done all that, the queue will be shorter anyway!

    So all we need is a separate printer to print the job queue window, then put a wooden table against the output tray, hang a camera from the ceiling above the wooden table, hmm, we need a way to make the camera click just as each new page falls out onto the wooden table, then we connect the output of that camera into the OCR program.

    I think we're getting a requirements document together here for an excellent solution!

    Note: On the serious side, GetWindowText of a top-level window gets the caption bar text. But if you pass the handle of a text box to GetWindowText, you get the contents of the text box.

  • (cs) in reply to Most Valued Poster
    Most Valued Poster:
    DaveK:
    Anyway, I don't see why we should take advice from someone who can't even balance his opening and closing quote tags!
    Hush your mouth! He's an MVP - I bet he's got a certificate and everything.
    Actually, IIUC, the MVP title isn't a qualification, but an informal community award, based on the level of someone's contributions to the public support forums. The concept originally arose based off of someone's automated usenet "Most-frequent-posters'-of-the-week" posts, and snowballed from there.

    IOW, it's the MS equivalent of saying you're like MPS!

  • (cs) in reply to Jay
    Jay:
    So all we need is a separate printer to print the job queue window, then put a wooden table against the output tray, hang a camera from the ceiling above the wooden table, hmm, we need a way to make the camera click
    This is a job for ITAPPMONROBOT!
  • Jay (unregistered) in reply to John Reese
    John Reese:
    Well, at this organization, users were not involved in testing. This was something I fought long and hard about, because a person who has been using the system for years could spot mistakes much faster than a developer who just walked in off the street. I was told the users didn't have time for such nonsense.

    I think at pretty much every place I've ever worked, the users are far too busy to be involved in testing, and indeed they are usually far too busy to be involved in requirements definition beyond sending a two-sentence email. Once the software is in production, then, of course, they are ready to discuss its shortcomings.

    Just a couple of weeks ago I complained to my boss that the users probably wouldn't get the requirements paper finished until 4:00 on the day I was supposed to have the coding finished. It turned out I was wrong. They didn't get it to us until the middle of the following week.

Leave a comment on “Cutting in Line”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article