RMS POS Crashes Before Printing Receipt

We sporadically have a situation were RMS 2.0.0115 POS crashes right before it prints a customer receipt. This seems to happen randomly and on different registers mostly when using credit cards but it also has happened with cash transactions. The problem is since RMS didn't print a receipt (and there is no record in the Journal or sometimes one that says something like "No Receipt Available for Display"), the cashiers ring the sale up again (since there was no CC slip to sign for the "original" transaction). Even though there is no trace of the original transaction in the sales history and journal the CC charge IS in the EDC batch but without the register number, Tender (CC) Type, partial CC number, cashier, and Transaction #, but the CC expiration date, approval code, date, and EDC batch # are there.

Does (or has) anybody else had this problem? If so were you able to resolve it and how?

Reply to
Alex
Loading thread data ...

Alex,

We ran for over 18 months and never had that kind of problem, but recently have had it twice in the last month. Unfortunately at the time I just wanted to get running again, so I did not write down the specifics of the error screen. It was something having to do with the inability to write to one of the tables. A reboot of the server cleared the problem.

At this time I still have no idea what caused the error, but (if) next time it happens I will try to get all the details to track down the problem. It is a big problem when it happens, because as you stated, the CC does get logged into the EDC batch. I also believe that all the items on that transaction get removed from inventory.

Marc

Reply to
Marc

We had this problem and the way we resolved it was by going into the client network utility and making sure the Named Pips was on the right side and it should be the first option on the top.

Then we went to the alias tab and created an alias.

This resolved the problem.

Hope this works for you.

Reply to
Isaac

Thanks for the reply Isaac. The only difference I have from your settings is the priority of Named Pipes. My protocols are setup as follows:

Shared Memory - 1 TCP/IP - 2 Named Pipes - 3

I read some brief descriptions, but don't know anything about the effect of changing these settings. We are one store running on a LAN. Will changing the priority of Named Pipes help? or at least will it not cause a problem? Any explanation or suggestions welcome!

Marc

Reply to
Marc

I would suggest you changing it and if this does not resolve the problem then change it back.

Reply to
Isaac

Alex, it would really help if you could post the exact error message that you encounter while printing a receipt.

Our POS used to crash when we have item descripti> I would suggest you changing it and if this does not resolve the problem

Reply to
Asad

Asas,

Unfortunately I don't have the wording for the very lengthy error message, but when/if the error happens again I'll write it down and post back to this NG.

Reply to
Alex

Can anybody confirm that in the below case the items do get removed from inventory? (I'm not sure how because they don't show up on sales reports so it seems that it would be hard to verify/track.)

Reply to
Alex

Are you referring to the Client Network Utility that is part of the Microsoft Dynamics RMS (menu group), which currently shows all protocols as disabled and has no aliases, or are you talking about the SQL (2005 express) Server Configuration Manager - Client Protocols, which currently shows Shared Memory, TCP/IP, and Named Pipes respectively?

Has the Client Network Utility that comes with MS RMS been replaced or superseded by the SQL 2005 (express) Server Manager?

Can anybody shine some light on this?

Reply to
Alex

Alex,

If you can remember any of the items involved, check it's item movement report and look for a transaction at the time the receipt errored out. In our case the item's movement was posted, just like the CC EDC entry. Apparently the error occurs after that DB posting takes place.

Marc

Reply to
Marc

Hi Alex,

To quote one of my earlier posts:

--------------------------------------------- I just applied Hotfix 2.0.0114, noting that one of the fixes in Hotfix 5 (2.0.0111) was: Error message when you have debit card pin pads enabled in Microsoft Dynamics RMS Store Operations: "Error #-2147467259 Database connection lost, application will be closed" I had all the stores with the problem reconnect their PINPads and immediately started getting calls again about the issue.

---------------------------------------------

I don't know if you're having exactly the same issue as I am, but they sure sound similar.

I have never seen anyone configure the alias and I haven't seen any configuration documentation on that yet. Anyone have detailed instructions on configuring an alias for 2.0 running on SQL 2005 Express?

Alex, if you're interested in seeing what I've already tried in resolving this issue you can do a search for "Brandon" and get a lot of info on what's been tried.

Reply to
Brandon Klassen

Hey Alex, Just a shot in the dark here, but what kind of hardware are you using for your terminals and server? I started encountering this issue when deploying newer Dell Optiplex systems into the field. Just curious as it's one of the roads I haven't gone down yet on this issue. I've had two suggestions that may make sense on the hardware side and they are:

  1. Serial port connected to PIN pad may not be closing the "connection" when it's transmitting the PIN. But so far I haven't had success when connecting the PIN to different serial ports, so this does not seem to be the issue for me.
  2. Network adapter is shaky and may be causing the database to drop connectivity. I get perfect pings and have very good networks in my stores with managed gig ether switches. Still, this doesn't mean that RMS isn't somehow causing the connection to drop. I may have to try turning off auto detect and setting them all to 100/full to see if it helps.

Either way, let me know what type of hardware you're running in your store.

Thanks,

Brandon

Reply to
Brandon Klassen

Brandon,

Thanks for your info but I'm not using any PIN pads at all. I'm also only getting this problem sporadically (maybe 1 out of every one or two thousand transactions or so).

I'm also not sure why we would have to configure an alias or change the default protocol order, but hopefully somebody (Glenn Adams?) can help with this.

Reply to
Alex

I'm using what I think would be very common and standard hardware for all our POS terminals (see below). Also if there is a network issue, which I don't think there is, why would the problem only happen right before printing a receipt?

Dell Dimension Epson TM88-IV (USB) receipt printer cherry USB keyboard (Incl mag stripe reader) USB mouse Metrologic USB scanner (model 9420 if I remember correctly) RMS 2.0 Hot fix 9 (v 2.0.0115) and that's it!

Reply to
Alex

Thanks Alex,

Interesting that it is Dell hardware, looks like you use the same keyboard we do. I run the Star TSP743 printers currently on LPT, so it's not likely related to the printer proper.

If you happen to see the error proper again any time soon you will probably see that it's a "database connection" error (I'm guessing here). As to why, I have no idea and I don't really believe it's a NETWORK issue but rather a CONNECTIVITY issue with the database. The TCP/IP is just another layer to look at when troubleshooting this thing.

In the store that I'm currently trying to resolve this issue for I just went ahead and made some changes that have been mentioned in this thread and will be monitoring the next few days.

I manually set every machine in the store to run 100/FullDuplex on their adapters. In the Client Network utility I set "Enabled Protocols By Order" to be TCP/IP first, Named Pipes second, and Multiprotocol third. Then in the Alias tab I selected the TCP/IP radio button and plugged my SO Database server's IP address into the "Server alias" field and left "Dynamically determine" checked by default.

I'll update when I have results, good or bad, on the config.

In the meantime let us know if your error is the "Error #-2147467259 Database connection lost, application will be closed"

Also, let us know if the dropped transaction hits your inventory or not. I do know that one of the first things to happen is RMS will charge the card and write the EDC batch, but not clear on whether it's making it all the way to the inventory or not.

Good luck,

Brandon

Reply to
Brandon Klassen

As mentioned earlier on in this post: I don't believe this is database connectivity issue because nobody ever gets disconnected, we just have a problem before printing the receipt.

Did you use the Client Network Utility on the MS Dynamics RMS menu? I don't think this utility works or is used anymore in RMS 2.0. Does anybody know?

I know when it drops the transaction the items on the dropped transaction don't make it to the (detailed) sales (history) or Z report(s), but I've not been able to find out whether they get removed from inventory.

If I find out more about this I'll post back again.

Reply to
Alex

Reply to
Dave

CC transactions barely require any bandwidth at all, so I don't think your ISP is the problem at all.

Are you saying that your CC receipts NEVER print?

After you reboot your computer (or restart RMS POS) you should not have to go into the Administrator at all. Make sure that when you configure (anything in) the Admin module that you are logged in as an Administrator account and not a limited user account or it won't save the changes. You probably also want to make sure that your are using the IP address of the database server opposed to host name.

Reply to
Alex

Reply to
Dave

It sounds like you either have some network problems or something is running on the database server that's slowing everything down. You also mentioned that it usually happens in the middle of the day so maybe you have some type of (virus / anti spyware) scan running at that time. The next time things slow down on the POS or Manager machine go to the database server and see if it is running slow as well, if it is then there's something wrong with the database server else there's probably some type of connectivity/network issue(s).

Reply to
Alex

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.