D
dbeavon
Guest
Thanks for all the helpful responses. From my perspective, I would not want to rely on a surrogate id (ROWID or identity column or whatever) in a way that assumes that it has meaningful information. Given that a user number (aka connection number) is found in _MyConnection._MyConn-UserId, then I would use that to access the _connect table, by joining to a corresponding field which also contains a user numbe r. ("_Connect._connect-usr"). The problem with making assumptions about surrogate ID's is that can introduce breaking changes as software evolves over time. A surrogate ID might be a guid, integer counter, or some other type of random number. It seems to me that the following code introduces some assumptions that might not always be true in future versions of Progress: FIND FIRST _Connect WHERE _Connect._Connect-Id EQ _MyConnection._MyConn-UserId + 1 Maybe I've been bitten too many when trying to derive meaningful information out of a surrogate ID (rather than just using it as a record ID). I suppose if the "assumed" relationship in the code above is well-documented then Progress won't quickly change it in a future version. But It seems unlikely to me that Progress wants us to write code that way - or why would the _connect table also have the explicit field for " _Connect._connect-usr ". As far as my original question goes, I think I will now have to start including the user number (aka connection number) when I find the related _connect. The PID alone is clearly not enough. Too bad we have a lot of legacy code (and Progress has a lot of legacy KB artices) that use _MyConnection._MyConn-Pid to find a _Connect record. Setting PASOE aside, that probably wouldn't have worked for other types of remote client-server code either!
Continue reading...
Continue reading...