RMS POS Crashes Before Printing Receipt

What are you doing in Administrator that you would need to have it connected to the database? If you are just launching admin to connect to the db, you do not need to do that. Both SOManager and POS will make their own connections to the DB. Administrator does not need to be running.

This is probably not related to your problems, but it is one less thing you have to do to run RMS.

Butch

As I have mentioned in several previous posts, we have this issue on a lot of our new Dell Dimension boxes. These are core2 duos with gig cards. We have very good network connectivity and SQL 2005 Express doesn't even come close to pegging with 2Gb RAM. I recently put a new computer into rotation and stuck the database on it. Within days we were seeing the issue crop up. I swapped the machine back to the old P4 it was running on and the errors went away immediately. I.e., in our case it has nothing to do with network connectivity or database speed.

I've been dealing with this one for over a year. Dave, do you have your primary database on a back office machine or is it on one of your POS terminals? Also, do you happen to be running Verifone 1000 pinpads or anything else on a serial port? As I've mentioned many times, when we have the store unplug the V1000 pinpad from the machine that does NOT host the database, the problem immediately goes away. Note that in our case we have one of the POS terminals running the database locally, and that one never drops connection.

Good luck,

Brandon

I'm about to pull my hair out over this! Since upgrading to RMS 2.x we've had the same problem. I've tried every possible solution I could find to no avail.

If I turn off the OPOS driver for the pinpad, this NEVER happens. If the pinpad is active it will eventually crash on any EDC transaction. One register crashes about 1 out of every 4 transaction. Another one crashes on

This one location is on a domain controlled environment with a headquarters server. There is one multi-location database and one individual store of another type hosted here. At first I thought it was a network issue, but now I know it isn't because the remote stores which have only one register are reporting this problem too.

It seems to only occur if the POS program has been idle for any length of time. A transaction get rung up and then just before printing it hangs and then crashes. I've checked power saving on every interface and device that has it, but it doesn't seem to make a difference.

We too are using Dell workstations with Dell (Star) printers.

I'd like to try a different > We sporadically have a situation were RMS 2.0.0115 POS crashes right before

Having a very similar issue - In event viewer the constant pattern is application error w/ faulty module ntdll.dll, version 5.1.2600.2180 (Event ID 1000), then application hang soposuser.exe version 2.0.0.110 (Event ID

I am also having this problem (system locks up at the end of a transaction). Its happening at a number of stores and it started happening after I updated from MSDE to SQL 2005 Express. Let's take one store for example:

Running RMS version 1.3

When I upgraded to SQL 2005 Express, I unistalled MSDE on the server, re-booted the server, then installed Express (downloaded from Microsoft). I did this because we were running into growing database size problems. After the install of Express, I used the SQL 2005 Express Management Studio tool to re-attach to my RMS database. MSDE or SQL 2005 are not nor have been installed on the registers. Since then, I have made the following changes trying to chase this problem down:

In the properties of the database, I have set Auto Close to false and Auto shrink to false. In the surface area configuration tool, I have enabled clients protocols Shared Memory, TCP/IP and Named Pipes in that order. The enabled MSSQLServer protocols are Shared Memory, Named Pipes and TCP/IP in that order (I don't believe that order is definable there).

The register continues to "freeze" when tendering a transaction. This might happen 2 or 3 times a day, or might go days without happening. We have seen the 2147217865 error, but not everytime. When this happens at one register, the other RMS stations also slow down. When we re-start RMS (with or without a PC reboot), things seem to work just fine. I have remotely logged onto their server while this is happening and can't find anything running that is eating up system resource. We are running Trend Micro Server Protect anti-virus on the server, however the RMS related folders, SQL related and spool folders are all excluded. The firewalls are disabled on the registers.

The RMS database has been re-indexed and shrunk (using the 2005 Express Studio tool)

I am at a loss and about to pull my hair out. I'm hoping there is a setting somewhere that I haven't found yet that will help this.

I thank every> Having a very similar issue - In event viewer the constant pattern is

I did determine what was wrong. It was a known issue. Specifically, "KB941267: Error message when you have debit card pin pads enabled in Microsoft Dynamics RMS Store Operations". This was supposedly corrected last October (10/2007) by RMS 2.0 Hotfix #5.

After installing the hotfixes up through #8, I still had the problem. I then received and email and a follow-up phone call by Microsoft:

"4/25/2008 12:44:00 PM PDT -- Vergel Santiago Called & spoke to Carla. I informed her that the issue "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" has been reopened since a lot of customers that hotfix #5 failed to resolve the problem. Unfortunately, we have no time frame when the fix would be released. Carla gave me her go ahead to add her contact details to the problem report."

What's the most disturbing is that this problem has been known for AT LEAST eight months and still no fix.

I did learn that if you turn off the OPOS driver for your pinpad, you won't crash again - at all - from this problem. However, that will drive up your merchant fees if you can't use the pinpad.

The bigest problem when it crashed was that you couldn't give the customer a receipt. I did come up with a way (sort of) to create a receipt.

1. after it crashes and you restart press f11 and select "recall for return"
2. the sale is displayed on the screen in return mode, press escape.
3. you will be prompted to cancel the transaction, select yes
4. if you are configured for it, a receipt will now print out with the canceled transaction. It will list all the items but no tender information. This is the best I can do.

-Carla

"Gregg" wrote:

I have a customer who has been experiencing the same problem. it happens randomly about once every two weeks. Today I trained them on how to take a snap shot of their screen. I assure you, when i get that screen shot, i will be openning a case with Microsoft. Perhaps with everybodies help on this forum, we'll find a solution!

I'm not using a pole display, or a pin pad, and do not have "database slow downs", but I'm still having occasional lock ups right before it (tries to) print a receipt.

Glad I'm still using RMS 1.3

I am testing the compactability of IBM SurePoe 4840-532 (1.2 GHz Celeron 512 MB Ram) with RMS ver 2.0. I used sample database. Every time I make a cash transaction, there is a run-time error 2147417848 and the whole software will shut down. Any help will be greatly appreciated.

Hello,

I have a client using MS RMS 2.0.0.115. They've been experiencing this same SQL error (2147467259) on their POS system on and off for many months. They have given up on their vendor, who never tried anything to fix it. I'm helping with some other issues, and thought I'd see what I could find here.

I took suggestions made here by others:

1. Changed the order of SQL communications protocols. It was "shared mem / tcp-ip / named pipes", so I disabled shared mem and made named pipes the first priority.

1. Configured the antivirus (Norton 360) to ignore the SQL working directories.

2. Configured an alias; however, there were no instructions on configuring the RMS to use this alias, so this solution is not complete.

The shop is small, one location, two systems. The SQL database exists on the POS system, which is where the errors are occurring. So, it's a "local" database. The error always seems to occur while processing a transaction--anecdotally it appears to typically be a credit card transaction, although I can't confirm this. As with other reports, the transaction appears in the batch but not in the journal. The customer does get charged for the transaction, but no receipt is printed.

My client has let their software subscription lapse, so I don't have access to any "official" forums (are there any?), or to the MS knowledgebase about the subject. I can't even tell what the current patch level is, and obviously can't obtain patches without the subscription.

I'm wondering if any of you who've posted about the issue have resolved it to your satisfaction, and if so, what do you think solved it?

Thank you in advance for any help!

Rob

Rob,

I was only sporadically experiencing the problem. It was exactly as you describe. I believe it was always on credit card. Transaction posts to credit card batch, but not to journal and no receipt prints.

I changed my SQL communication order exactly as you describe in #1 and have not experienced a problem since, about 3 months. The weird thing is I never had the problem for over a year, then saw it happen 3 or 4 times over a month until I made the fix described.

I would hazard a guess the problem was introduced with a service pack ;). I am not completely up-to-date, but now have SP2 and one hotfix after. I may have added SP2 near to the time I changed the communication order, so it still possible that plays into the problem going away, or at least it SEEMS like it has gone away at this time.

Good luck,

Marc

I used to have this problem on 2nd station because my data is sitting on first one. I changed router and I do'nt have this problem any more. I am using a Linksys N150 I also port forward range 34000 to 3500 and make sure your router's firewall is off.

I had this exact problem with MSPOS.

In my case the culprit turned out to be hardware -- most likely the power supply on the POS PC just couldn't handle the load from the PC itself, all the USB peripherals and, most importantly, the powered USB printer. The problem went away after we replaced the printer with a plain USB model and got a self-powered USB hub for all peripherals.

I wonder if MSPOS and RMS both use the OPOS check health function frequently, but don't handle failures or non-responses gracefully.

settings, one is using a HTML status screen, is using a debit pin-pad and is using the built-in credit card processing within RMS.

database. In the past it was recommended to set TCP/IP as the first protocol and then Named Pipes. Reversing the order seems to have fixed the issue.