Memory file conflicts
Posted 06 September 2006 - 09:41 AM
For info, wer're on 5.5 r308, running on VMS
1. Create a memory file and a simple screen function for maintaining it.
2. Add a record in one screen but leave the screen in the record (i.e. don't commit the add)
3. Lookup the same record in another session - so far so good, it doesn't exist.
4. Now try and add the same record in the other session - you'll get an error saying it already exists.
5. Finish adding the record in the original session. Now you can add the same record in the other session.
I've logged on & off, tried it with another user - still get the same results.
It's made me a little wary now about using memory files - something I'd previously believed to be pretty stable.
Posted 06 September 2006 - 10:18 AM
Just tried this on Tru64, 5.5r345. Did not get any problem...
Posted 06 September 2006 - 01:34 PM
As such, on two screens, I can add apparently the same record (with no error).
Just to ensure a valid test, here's what I did:
CO- AUTO EXTERNAL FILE KEY RECORD
DIV SEQUENCED RECORD FORMAT TYPE LENGTH LENGTH
FILE NAME: TEST2 Y MKY 6 10
DATA MAX FILL SPECIAL ARRAY
SEQ TYPE VARIABLE NAME LEN CODE DISPLAY-CODE CHECK SIZE
--- ---- -------------------------------- --- ---- ------------ -------- -----
001 K TEST_ONE 3
002 A TEST_TWO 3
On two different screens, I then added the values TEST_ONE = "1 " and TEST_TWO = "ONE".
Both added and read without error.
Edited typo in revision
Edited by Rick Young, 06 September 2006 - 01:35 PM.
Posted 06 September 2006 - 01:43 PM
In case I'm wrong though I definitely had different sessions, with different users and had logged both in and out a couple of times just to make sure.
1. Add record in one session
2. Add record in second session
produces no error
1. Start to add a record in the first session and get past the read field
2. Try to add a record in the second session
does produce the error as described. So it's not that the actual records in the files that are the problem - it's while a record is still being added that it will conflict with another session.
So with your test in session one add TEST_ONE = '1' and sit on the TEST_TWO field, then go to the other session and try and add the same record. What happens?
Posted 06 September 2006 - 01:47 PM
I presume its some bug with shared memory.
When you add a record into a ProISAM file, and have not yet commited, its added into shared memory as a lock, so that a record locked messasge can be displayed if someone else tries to add the same record.
I presume, that since Memory files are based around ProISAM files, that on some platforms or conditions, the kernel is not ignoring the lock table for Memory files....
Posted 06 September 2006 - 01:49 PM
With regards @TERM, I didn't really mean to state it so specifically - I just interpret the equivalent behaviour of how I understood them to work
Posted 07 September 2006 - 07:39 AM
I'd bet a small sum that this is a piece of stupidity where ProIV are simulating record locking in add mode for a file type that doesn't support it (eg. RMS) and forgetting that should not apply for memory files.
Yours faithfully from the other side of the room.
Posted 07 September 2006 - 07:40 AM
Maybe group psychosis?
P.S. I have demonstrated this to witnesses so I'm not going mad
Anyway, I've tested on solaris 5.9 & windows server 2003 both
of the poster and do not represent those of any organisation.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users