ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Sales >> problem in so-a.
http://www.istechforum.com/YaBB.pl?num=1161787940

Message started by captkahunah on 10/25/06 at 06:52:20

Title: problem in so-a.
Post by captkahunah on 10/25/06 at 06:52:20

Hi! I'm having a problem when entering sales orders... I'll get the header filled out, but when I try to move on to the line item screen, I get an error message "BKSLMSTR in use by another user". (I'm paraphrasing) I have noticed that this seems to happen when my boss is paying bills (accounting-ap-b) in the evo system, and clears when he is out of it.

Is this supposed to happen? If so, is there a way around it so that he can work and I can still get the sales orders done in a timely manner?

Title: Re: problem in so-a.
Post by Lynn Pantic on 10/25/06 at 08:36:52

I suspect you do not have the error message correct, I suspect it is BKSYMSTR, not BKSLMSTR that is locked. The file stores both the "Next" sales order number and "next" check number so if AP-B is cutting manual checks and pulling check numbers the same time you are trying to pull sales order numbers, there could be a conflict but only if you happen to hit the file at the same instant. I will take a look at AP-B and make sure it is not leaving the file open.

Title: Re: problem in so-a.
Post by captkahunah on 10/25/06 at 09:20:03

I suspect you're right about me getting the error message wrong... I was doing it from memory, without it in front of me.

The problem isn't a one time in a thousand type of thing, if that helps... I am consistantly locked out of sales for the entire time his computer has AP-B open.

Title: Re: problem in so-a.
Post by David Waldmann on 10/26/06 at 03:47:56

I just did a test:

Writing a manual check in AP-B, have the dialog open where you enter the check number. Open SO-A, enter header info, go to line item screen. No problems.

Same thing with the "Do you want to reset the Check Number Counter?" Dialog (I did get Btrieve error 80 on BKSYMSTR when AP-B tried to reset the check number, but it doesn't hang anything - just doesn't reset the check number).

Same thing after voucher is completely entered and left open.

ISTS has done a lot of improvements on record lock problems - what version are you on?

Title: Re: problem in so-a.
Post by captkahunah on 10/26/06 at 05:43:08

I'm on Evo-erp version 2006.1 8, acording to the "about" page. I'm not above thinking that it could be unique to my system or something, but I do need to know how to solve the problem...

Did you do your test on the same machine, or did you have ap-b and so-a open on different machines (which is what is happening to us)?

Title: Re: problem in so-a.
Post by David Waldmann on 10/27/06 at 03:57:43

It was on the same machine.

Title: Re: problem in so-a.
Post by David Waldmann on 10/27/06 at 04:03:30

Just tried the same thing(s) running AP-B on one machine and SO-A on another. Sorry, but no problems here.

Title: Re: problem in so-a.
Post by Lynn Pantic on 10/27/06 at 08:35:36

If you have your boss open AP-B and then load the Pervasive Monitor on the server, does it show the BKSYMSTR file with a record lock? It shouldn't until the instant of saving a manual check when the check number is incremented. Entering normal vouchers shouldn't lock it at all.

Title: Re: problem in so-a.
Post by khays on 10/30/06 at 10:07:12

further explaination of original problem - on the system being used by captkahuna

I used the monitor to watch the lock status of bksymstr during the manual check writing procedure.

a 'single' lock appears upon hitting return on the '...want to reset check number counter' question and remains until the 'did the check print properly' question is answered.

what is happening is that the person writing the check agrees with the suggested next check number, saying yes to reset counter, yes to print manual check, selecting graphical form, then previews the check, then prints. The whole time bksymstr is locked until then 'printed propery' question is answered.

the person writing checks is new to evo and still checking all keystrokes carefully. I'm not sure there is a better way to handle the lock for check number in that until the check prints properly you probably don't want to update the counter but you also don't want someone else to get your check number while your trying to print a check.

Title: Re: problem in so-a.
Post by captkahunah on 11/03/06 at 06:58:05

Thanks to Khays for describing the problem better than I ever could...

so any suggestions for how to get around it?

Title: Re: problem in so-a.
Post by David Waldmann on 11/06/06 at 04:56:24

I think the only thing that can be done is to get the person writing checks comfortable enough with the process that they just print them and say they printed ok. Unless you can get ISTS to rewrite the way DBA works, which I suspect would be extremely extensive.