Hi Ray,
thank you for the thoughts. Option 1 won't work for my situation, as my intent is to allow some segment of my clients to come in over the Net and place their own orders on my internal network (1 of the 2 main motivations for me to make the transition to Sesame from QA), and each of them would have to have the correct printer installed on their local system.
I'm intrigued by the idea of option #2, though.
Although, now that I think it through, my scheme is to have the remote user come into my network through a VPN SSL device, log in, and get onto a dedicated XP desktop in my office that shows ONLY a Sesame order screen menu. They then logon, and are presented with an order screen that is populated (and restricted) to their personal data (name, address, phone, etc) and their unique set of Priced items to order. So, the 'client' computer is not the one the remote user is sitting in front of, it's the dedicated workstation in my office, so it will be able to print to my network printer with no problems. It was late last night when I posted my question (I just got up and running the ability to connect through the Net from my house to my office last night late), and I glossed over the fact that both client and server will be physically in my bldg, therefore not a problem. It would only be an issue when one of my employees was entering orders remotely, using a different SalesOrder form than the end users will be using. For my clients that will want their own Sesame client on their computer, I can have the "Print/submit" button just save the record and notify someone in my office to print those remote orders - perhaps incorporating your option #2 suggestion to generate a quick report of records 'needing printing'.
It would be nice to have some kind of ServerPrinter() command, as online ordering is becoming so prevalent, but I'm never surprised at the seemingly bottomless well of frustration that is the 'Microsoft printing world.'
Thanks so much!
|