Of course, the item's code is part of primary or alternate keys in a lot of other files invoices etc. So, normally, when the customer wishes to change the item's code, I would have to scan all of these files and change the code there also. Instead of doing this, I figured an alternate solution: Change the item's code from primary to alternate with no duplicates, put another field in the item's master file as the primary key which would act like an autoincrement field and use this new field as a "link" between the master file and the rest.
By the way, I made this new primary key autoincrement and invisible to the customer. If I made it user-insertable he would just shoot me. The problem occurs when the customer wants to enter a brand new item: At that time I come in need of knowing which key is duplicate.
My intention is, if the now alternate "master item code" is duplicate, just inform the user that the item already exists and ask for an other code. If instead the new autoincremented primary key is duplicate, I just increment it and try to write again the record. I hope my english is good enough to make all this mess clear to you. My problem is not how to handle a duplicate record condition, but to know which key is duplicate.
Thanks anyway. And isn't the code posted by Tom k5tm a good starting point? Hope This Helps, PH. Want to get great answers to your Tek-Tips questions? It sure is as i stated in my answer to him , I was just wishing for a more direct solution. On a second thought, there may be also a "multiuser" issue with Tom's solution; not sure enough, have to check it. I think your problem is on how you are allowing the user to enter a new record.
In this type of application the user can only do the following operations Create Delete Update All the above have one thing in common or should have!! Before allowing the remaining of the operation to continue you need to verify if the "KEY" already exists. If Doesn't On Create mode you should present the user with a blank record and eventually with the "KEY" field protected. At this stage you have part of your problems solved. Loop done just a few times to allow for the record to be released by the other users, and only at the final stage of your create mode operation.
This may issue an invalid key, but as you know it can only be that particular field so you inform the user that the record already exists. What you do then depends on how your application works. Hope the following is of some help.
Regarding the separate file for holding the sequence number, I don't quite like it, first because of the extra overhead updating 2 files instead od one and second because a lot of things could go wrong between the "get the sequence number" and "update the master file". I used this technique some years ago but I've abandonded it since. I'll check it and post the results. Thank you very much for your valuable thoughts. It does NOT work if there are no records in the file and some other process writes a record between this process's "end-start" and "write": Both processes will get an AutoIncrement of 1.
As for something going wrong from getting this sequence, and updating the real file, it is true it can happen, but it can happen anyway in other situations. This does not apply to VSAM sequential files.
Sequential files only. A sequential READ statement was attempted and no next logical record existed in the file because the end of file EOF had been reached, or the first READ was attempted on an optional input file that was not present.
A sequential READ statement was attempted for a relative file, and the number of significant digits in the relative record number is greater than the size specified for the relative key data item. Indicates a sequence error. Prime record key values must be in ascending order. Indicates a duplicate key condition. An attempt has been made to access a record, identified by a record key prime or alternate for indexed file, relative key for relative files , and that record does not exist in the file.
Operation failed because an attempt was made to write beyond the externally defined boundaries for an indexed or relative file; or a sequential write operation was attempted for a relative file but the number of digits in the relative key value exceeded the size specified for the relative key data item.
Or Disk full. This can also happen when a sequential file is open for input and an attempt is made to open the same file for output. Micro Focus only. This condition indicates that an attempt has been made to write beyond the externally defined boundaries of a sequential file. Or Disk full for a sequential file or sort file. The I-O phrase was specified but the file would support the input and output operations. Attributes that are checked are organization, index keys prime and alternate , block size, and maximum record size.
This is usually caused by a conflict with record-length, key-length, key-position or file organization. Other possible causes are: 1. Alternate indexes are incorrectly defined Key length or position, duplicates or sparse parameters. The Recording Mode is Variable or Fixed or not defined the same as when the file was created. After spending much time checking the library lists which were fine , whether there were any other objects with the same names resident on the machines there weren't and going through the file and object descriptions with fine-toothed combs there were no differences , we decided to rebuild the offending files on the development machine.
Yes, you guessed it, suddenly everything was Ok again. All's well that ends well, but it still doesn't answer the mystery as to how it happened in the first place.
One of you mentioned in your note that you had experienced problems with the status 95 before - don't forget that when processing a logical file within a program, all other related access paths are also checked, even if the file isn't specified in the program. So if you are doing something to one logical that will cause duplicates in another logical that is related to the same physical, you may well get a status Sounds confusing, so check out the manuals for a better description of this.
Thanks again for your time and interest. Kathy Cheung. Obviously, if some other logical stipulating unique key s exists over the physical file, then any attempt to write a record to the physical could fail with an invalid key error regardless of which logical the write is performed on.
The "95" status is generated at open time only, as far as I know, and only looks at the attributes of the actual file opened, vs the attributes specified on the SELECT statement - I can't figure how any other logical could enter into this equation.
The two approaches seem to me to be significantly different, and in the latter case, would appear to impose quite a performance overhead if implemented as stated i.
Has anyone had any problems when ignoring the "95" status when opening a file with a unique keyed access path i.
0コメント