Delays, Locks Recalling Transactions

When recalling a transaction at the POS, it can take a long time while we are busy. Often, during and after the busiest part of the day I get the error:

Run-time error'-2147467259 (80004005)':

Transaction (process ID 65) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

In the morning, the system runs very fast and I can recall a transaction from any time, any range of time, almost instantly. The server reindexes every night. I am using Sql Server 2000, SP3. My database Server Is two mirrored HDDS SATA 7500 rpms, 2 gig 400mhz pc3200 memory (2x1gig), p4 3.0 ghz running WIN SBS 2k3. We need to recall transaction druing the day. During the busiest part of the day, the server is utilizing only 2-5 % of the CPU (unless I am recalling a transaction or running a report, then it jumps to

50%), and only about a gig of ram. I don't believe I need to upgrade my hardware, but what are my options? The database size is 920 megs, growing 15 megs a day, but we haven't hit a busy weekend yet (more than double the transactions). Any suggestions would be appreciated.

Patrick

Reply to
Patrick
Loading thread data ...

I'm not going to pretend that I can diagnose this based on newsgroup postings. You should get either your RMS reseller or a SBS/SQL Server consultant on site to run diagnostics on this.

But...

You can configure the memory usage in SQL Server - just because the server is only showing 1GB in use, doesn't necessarily mean that SQL Server doesn't want to use more!

In SQL Server Enterprise Manger, right click your server and select Properties. Look at the Memory Tab - how is SQL server configured? Look at the Processor Tab - you could try giving SQL Server a higher priority for the CPU.

What you really are going to need to do is look at the Management Folder under your server in SQL Enterprise Manager and monitor the current activity - you will see locks appear and disappear and be able to see where they locks are coming from and even the SQL Statement that generated them. This is the part where you are going to want some help...

You didn't mention how many registers you are running, how many management stations are connected during these peak times, or your transaction volume. These are all important for server sizing. What about your network - Wired/Wireless, 10/100/1000?

On a purely RMS note, you MIGHT get better performance if you set customer before trying to recall the transaction. RMS will only show transactions that are assigned to the current customer, but I don't know if the filter is applied as part of the query, or to the recordset after it is returned.

Glenn Adams Tiber Creek C> When recalling a transaction at the POS, it can take a long time while we are

Reply to
Glenn Adams [MVP - Retail Mgmt]

Hi Patrick,

RMSynergy have written a range of Add-ons that enhance the capabilities of RMS. One of these add-ons is a Transaction Refund function. We too have had the problem where after a busy day trading with 12 lanes trying to recall a transaction for return can prove very difficult often causing them system to grind to a halt. This add-on enables you to enter the transaction number and it displays all the items in that transaction. You then have the choice of ticking the items you wish to refund before you conclude the transaction by refund.

If you would like to discuss this add-on further please contact me and I will pass your details on to your local RMSynergy partner.

Kind Regards

----------------------------------------------------------------- Grant Chaplin Channel Development Consultant snipped-for-privacy@rmsynergy.com

RMSynergy snipped-for-privacy@rmsynergy.com

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

Reply to
RMSynergy

not that this would be your exact situation, but i recently saw a KB article about recalling transactions that contained over 300 records taking too long to execute. It had to do with indexing.:

customer source KB:903749

Reply to
root

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.