Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
DonBakke
About
- Username
- DonBakke
- Joined
- Visits
- 3,226
- Last Active
- Roles
- Administrator
Comments
-
This is unfamiliar to me. Do you have an example of how this is coded in straight SQL?
-
I don't know whether mixing single keys and two-part keys in the same table is valid. That depends on how you want to define valid. It is certainly valid from the standpoint that the flexibility of OpenInsight's database will allow it. Since dicti…
-
Even so, no editor can currently recognize a column lock, so the potential for data to be overwritten still exists. Locking in OI is fundamentally a social contract, so ALL locks allow the potential for data to be overwritten. You trust that other…
-
I don't have any experience with this message. I searched all of my existing archives of articles and notes and came up empty. I see the error in REVERROR.DAT next to other lock-related errors but I'm unsure what specifically generates this error.
-
I think your principles are sound but I don't think they are applicable to OI. Given that using Lock() against a column also locks the record, I question whether locking a column does anything meaningful. If anything, it seems to me that more overhe…
-
I assume you are just using the WriteV statement to update these individual date fields?
-
do you know if OpenInsight can guarantee that the dummy KeyID won't match a real keyID for an existing row? I have absolutely no idea about this. See my answer below. Is ColumnName concatenated with KeyID with nothing between them? Yes, that is …
-
Just a quick correction to your code (which I assume was not tested but quickly typed out). Unlock() uses the name of the table not the handle to the table. You can also use Unlock() for the record key itself without having to resort to the Unlock s…
-
Vince, sorry. I don't think I read your original post correctly when I first responded. Your second post set me straight. I am able to duplicate the issue. Lock and Unlocking columns still leaves the record locked. You have to explicitly unlock the…
-
I don't know the underpinnings of RTI_Lock_Owner(), but I have no doubt that editors only look for record locks.
-
Maybe it is an old bug that will disappear with an upgrade to OI 10. Just tested. Sadly this is not the case.
-
I see. I thought you already came to the conclusion that this likely a problem with the compiler being overly zealous with the variable starting with the name of a keyword and this isn't anything on you. It just seems to be an unexpected (and unwant…
-
What specifically are you wondering about? You make some interesting observations (which were honestly a surprise to me) but somewhat par for the course with Revelation. I am not sure I caught the issue you are still puzzled about.
-
That should definitely help. In our early efforts to do what you are doing we discovered these "memory leaks" after running our code for extended periods of time. I think the sample code I included in this blog post does a proper release of each obj…
-
Stopping the event flow (aka stopping the event chain) is limited to the links associated to the currently running event. By "links", I'm referring to: * Script Event handler * Promoted Event handlers (pre system) * System Event handler * P…
-
Right. I agree with your expectations in principle but you do know that the SRP Editor relies upon Blint, which is the routine that the Revelation Editor uses to identify potential VNAVs, correct? We do a little post-analysis to clean up their findi…
-
So again...
-
Does this mean you do not need any help at this point?
-
I agree that there is a false positive being recorded on line 1516, but the OI editor is reporting the same false positive...correct?
-
I just want to commend you for creating a unit test for this!
-
That's a good question. I don't know if I have ever had that situation come up before. I think BASE_MFS should be updated to identify if the table is an alias and attempt to find the table commuter for the original name, but in the meantime you prob…
-
You don't need the "OLE.". Just use the eventname. Agreed, as long as we are only discussing the registering of OLE events. When interacting with properties or calling methods, we consider prepending with "OLE." to be best practice.
-
Could? Yes. Would? Probably not, but might consider if there was an intent to completely move away from O4W. O4W requires that you use RUN_OECGI_REQUEST. The HTTP Framework requires that you use HTTP_MCP. Thus you would need two different OEngineSe…
-
Why isn't this "Best practice" in your documentation? That is a fair question. For one, this only became best practice as of OI 9.x. Our controls have been around since OI 4 and we still have clients using OI 8 and our controls. Originally using A…
-
All the above are correct.
-
Your next level feat will be mastering transaction processing.
-
A guess this is a bittersweet conclusion. Regardless, I'm glad you solved your problem and you also, ironically, proved that OI works as expected.
-
I'm 99% certain it offers no performance benefits. It is really to isolate and protect the field being operated on. I think relational indexes use WriteV for this very purpose. Well, I have no other ideas to offer. This behavior is unexpected. Hone…