The only suggestion that I would have would be to create a timer (System.Threading.Timer) with a call back and try to fill the BO on the thread (if you try to fill and it is locked).  Then you could display something to the end-user saying that the "record is locked because RPG sucks!" and continue to try to fill until you get the data.  At least it would then be automated, but it would just not fix the RPG problem.  Can't fix the RPG guy

It is definately the way the old RPG programs are locking the records that is the problem. I can have DB2 records open for edit in a number of other tools/methods and the SF collision detection works just like it is supposed to. So far as I can tell that is just the way they do/did things, our RPG guy was telling me stories of people going to lunch and leaving records open and people walking around to see who it was and closing the record. In fact he didn't understand why I was distressed at this finding, "thats how it is supposed to work".



I know this isn't a SF thing, I was just tossing it out because I am a little lost as to how to address. In my maintenance screens I do a pretty common thing to just fill my BO and provide browse/search/edit capability.... none of those screens will load because the fill hits the "locked" record and just sits there until a thread pumping error is generated (about a minute).





Uhggggg DB2 (or RPG in this case) !!!!
















Keith Chisarik

Are there database options that will allow your SELECT query to continue processing?  I know in several environments you can set a max delay on the database... if the query does not succeed within a specified amount of time, it will just return, generally with all of the results except that record.

If it's not a configuration issue with the RPG program, then it certainly be too much of a hassle (and most likely not possible) for the RPG program to be changed so that it locks the row differently, so that's probably not an option.

Some row locks allow you to read the data while the row is locked, but I don't know enough about DB2 or the way that the RPG program is locking the row to definitively tell you what to do.

Hi Keith,

I know nothing about either but I would think the issue is not in DB2 (being a high end multiuser db) but within how RPG is accessing the data, e.g. maybe applying a table lock so it ensures nothing changes in a table while it generates a report. I would have a close look at how RPG is configured.

Cheers, Peter

I have the following problem.



If a user has a DB2 record opened with an RPG program I cant even read it, thus all my fills fail and my program hangs.



Not knowing DB2 intimately, I had not anticipated this problem. Any ideas? My app has to integrate into an environment where it will co-exist with a large number of legacy RPG programs. I was getting ready to put the first module into beta onsite and ran into this.



I hope the guys get back soon......

Keith Chisarik