Lee Walters

OK, For future reference for people - I think we've solved this problem and another one we've had with files in B Mode - see my previous query on this.

It's taken me better part of a week to get to but we eventually found out that our indexes were slightly off on the tables in question. So I re-created the index and trawlled though the SQLServer books and found a very interesting stored procedure - sp_indexoption which basically lets you set the type of lock you want on the index - either Table/Page or Row locks.

This also solved our problem with files in B mode. Or seems to have at present - will have to do more testing on this one to confirm but things are looking good.

It's simple, think of this - a screen to input records. The file we are writting away to has a mode of B/B/D/L. The key to the file has already been established before you enter the screen. (Basically we get it from a control file before entry into the function).

The first person into the screen, get's in fine and can enter records. I've put a UMSG in to display the key on entry and its different every time.

If anybody else tries to go into the screen then they get a record lock message. I've now put a UMSG in the lock logic to display the key as well and exit the screen so not to kill the system. If I take the UMSG and exit out from the lock logic and go into the screen twice at the same time to get the lock message, then in the first session exit from the screen normally, the second session that was locked is allowed entry into the screen.

Hope that makes sense!

Tony,

It will work fine as long as you get your system paramters sorted in /etc/system!

We're running it with no problems.

Lee

Hi All,

sorry for not replaying - Holidays :-) Haven't touched a PC for just under two weeks! ah bliss - and now back to the grind!

SQL_TRANSACTION_ERROR=Y We're not using this under our Oracle env but we are in the SQL Server ENV so not sure!

I know officially hate SQL Server <_<

George,

Sounds a pretty good idea. Only problem is, I know it's an SQLServer system so I don't need to worry about checking for the DB Type. We keep all our systems seperate!

Cleve - Don't even go there !! sadly it's not an option and yes, it's painfully slow!

Looks like I'm still going to have to go with the &#@SUPP-COMM method (OUCH!)