Revelation Software is pleased to announce the availability of a new standalone patch, OpenInsight 9.4.5 Patch 042720. This patch includes fixes to:

- SI_REDUCTION to resolve sorting problems when using left-justified wholly numeric values;

- BTREE.EXTRACT to ensure that null values are included in lt and gt extractions;

- O4WTABOX to properly parse the plugin version to use, as well as other enhancements;

You can read the instructions and download the patch from the Works Downloads section at this link.

If you have any questions or problems, please feel free to post them here.

- Bryan Shumsky

Revelation Software, Inc.

- BTREE.EXTRACT to ensure that null values are included in lt and gt extractions;

Hmm, I wouldn't have thought this was a bug.

For instance, if you are searching a date index for dates earlier than a certain (positive) date then you wouldn't necessarily expect to also find records that weren't even dated. Nor expect a search for dates later than a certain (positive) date to behave differently (by not including undated records).

I'd expect records without this data to not be considered for such a search. Whether or not null values are included would typically be handled by its own search criteria (Or NULL, And Not NULL, respectively). Eg, if nulls are to be included then explicitly add that search for null as another search value (which technically is just adding a @VM to the search value)

To retain backward compatibility for this use case, one would now have to add a 'And Not Null' criteria to the search so that null value results get filtered out.

Thoughts? I presume this was done for consistency with rlist SELECT?

Cheers, M@

Vernon Systems

Thoughts? I presume this was done for consistency with rlist SELECT?

Correct.

Long answer:

While writing OI10 I've been trawling through the rlist, reduce and Btree.Extract code for performance improvement opportunities. I have a benchmarking program which runs a set of queries in OI9 and OI10 using index columns, non-indexed columns and BTREE.EXTRACT. When the results differ then I assume I have a problem.

We had a reported problem with selects on left justified indexed numeric values which we traced to SI_REDUCTION. In fixing that I found that the range operators (LT, LE ) could miss the nulls, so the result of selecting on an indexed column was different from the result of selecting on the same column without the index. I fixed it in SI.REDUCTION, now BTREE.EXTRACT was different from SI.REDUCTION. I modified BTREE.EXTRACT to match SI.REDUCTION.

When the same SI_REDUCTION issue with left justified numerics was reported for 9.4 I back ported the SI.REDUCTION from 10 to nine and threw in the BTREE changes for good measure. The BTREE changes only affect cases where btree.extrac calls BTREE.SUB.BETWEEN or BTREE.SUB.FROM.TO . Btree.Sub.Between is used for <, >, and ~, Btree.Extract.From.To is used for ⇐,>=,…

If you want we can release a compatability patch with uses a config setting to switch between the BTREE.EXTRACT and the just-released version.

If you want we can release a compatability patch with uses a config setting to switch between the BTREE.EXTRACT and the just-released version.

Thanks Bob,

I'd be curious to know how this might affect others generally, and whether it's worth configuring. We could just change our code to compensate - we tend to use Btree.Extract exclusively for searching indexes.

But if you going to add a configuration setting then it would be useful to specify whether nulls

- have an ordinal sequence value, respected in range searches

- or are 'undefined' and excluded from range searches.

and apply that consistently to both SI_REDUCTION and BTREE.EXTRACT

Cheers, M@

Vernon Systems

Revelation Software is pleased to announce the availability of a new standalone patch, OpenInsight 9.4.5 Patch 042720.

If you have any questions or problems, please feel free to post them here.

Hi, Bryan. The patch does not seem to update the version shown in the OpenInsight About dialog or the TCL Who command. What is the best way to confirm the patch installed correctly?

Don Bakke

SRP Computer Solutions, Inc.

Hi, Don. Since Matthew has already raised the idea that maybe the btree change should be optional, we're probably going to introduce a configuration record and remake the patch. So you'll be able to tell that the patch was applied by the presence of this config record.

I'll post here again when it's ready (probably in another few days…)

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Hi, Don. Since Matthew has already raised the idea that maybe the btree change should be optional, we're probably going to introduce a configuration record and remake the patch. So you'll be able to tell that the patch was applied by the presence of this config record.

I'll post here again when it's ready (probably in another few days…)

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Having the version number updated would be a far better solution for us people who have to maintain variuos client systems far and wide.

Hi, Don. Since Matthew has already raised the idea that maybe the btree change should be optional, we're probably going to introduce a configuration record and remake the patch. So you'll be able to tell that the patch was applied by the presence of this config record.

I'll post here again when it's ready (probably in another few days…)

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Having the version number updated would be a far better solution for us people who have to maintain variuos client systems far and wide.

Hi, Barry. I think you and Don may both be misunderstanding what this patch contains (or else I'm misunderstanding you both). This is NOT a roll-up patch - it does NOT contain all previous patches that were released since 9.4 came out. If it was a roll-up, cumulative patch, then indeed it should update the version number.

However, since this is "just" a standalone patch, fixing a few elements in isolation, changing the version number of OI doesn't seem to make sense? If you had a series of these patches (as we have had in the past), then changing the version number of OI doesn't tell you which ones had been installed - it only tells you which one was the LAST one to be installed. So instead of changing a single record that would get overwritten each time (the "about" record), we SHOULD have a log of all the RDKs/patches that have been installed, and each new patch should update that log.

Towards that end, then, we will revise this patch so that (a) the new BTREE.EXTRACT functionality is configurable, and (b) it (and subsequent patches, in both 9 and 10) update a new record, RTI_SYSUPDATES, in SYSENV. This way, you can always refer to that record to see which updates were installed, and when.

I hope this makes sense - let me know if it's still confusing, if you still don't understand/agree with the fact that the version number isn't updated, or if you have any questions.

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Hi, Barry. I think you and Don may both be misunderstanding what this patch contains (or else I'm misunderstanding you both). This is NOT a roll-up patch - it does NOT contain all previous patches that were released since 9.4 came out. If it was a roll-up, cumulative patch, then indeed it should update the version number.

Speaking for myself, I was not confused regarding what this patched contained. However, I probably didn't catch on that this patch was designed so it could be installed on versions of OI prior to 9.4.4.

I think the confusion is in the labeling of this patch as "9.4.5", which suggests a versioning change. You've had other "stand alone" patches which don't cite a version, but simply say "for OpenInsight 9.4", which more clearly indicates that this is a stand alone patch.

Also, "roll-up" patches have always seemed to me to just be a convenient way to install multiple patches. The fact that they might update the version is simply a consequence of the patch including the latest version.

Don Bakke

SRP Computer Solutions, Inc.

What are your thoughts regarding having some kind of "patch log" that each patch, moving forwards, updates when it is installed? I was imagining that would make everyone's lives easier…?

- Bryan Shumsky

Revelation Software, Inc.

What are your thoughts regarding having some kind of "patch log" that each patch, moving forwards, updates when it is installed? I was imagining that would make everyone's lives easier…?

- Bryan Shumsky

Revelation Software, Inc.

Funny, just as I clicked the Save button I thought about that and considered posting another response along these lines. Yes, anything that lets us know what has been installed/patched/updated would be helpful.

Don Bakke

SRP Computer Solutions, Inc.

After taking into account the various feedback you all posted here regarding this patch, we have updated the patch and the Works download page.

The change to BTREE.EXTRACT is now explained more fully, and a configuration record has been added to allow this functionality to be optionally implemented. By default, the behavior will remain as it has been, though you can now update the configuration record to turn on the "fixed" behavior. Please note, the "fixed" behavior IS THE DEFAULT IN OI 10.0+.

The RDK has also been updated to record the date/time it was installed in a record, RTI_SYSUPDATES in SYSENV. The functionality to have an RDK update a post-install "status" record has also been added into OI 10's "Deployment Definition" process.

Please download/re-download and re-install the patch, and as always, please let us know any comments/thoughts that you have on the issue.

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Please download/re-download and re-install the patch, and as always, please let us know any comments/thoughts that you have on the issue.

Thanks Bryan - looks good

Cheers, M@

Vernon Systems

After taking into account the various feedback you all posted here regarding this patch, we have updated the patch and the Works download page.

The change to BTREE.EXTRACT is now explained more fully, and a configuration record has been added to allow this functionality to be optionally implemented. By default, the behavior will remain as it has been, though you can now update the configuration record to turn on the "fixed" behavior. Please note, the "fixed" behavior IS THE DEFAULT IN OI 10.0+.

The RDK has also been updated to record the date/time it was installed in a record, RTI_SYSUPDATES in SYSENV. The functionality to have an RDK update a post-install "status" record has also been added into OI 10's "Deployment Definition" process.

Please download/re-download and re-install the patch, and as always, please let us know any comments/thoughts that you have on the issue.

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

The functionality to have an RDK update a post-install "status" record has also been added into OI 10's "Deployment Definition" process.

Is this the Version/date section in the deploy create?

Is this working in the 10.0.8 version or still to come

What does the record format look like so I can create the record and use it im my 'About' screen…resdy for future.

Hi, Barry.

This new feature in 10.0.8 Deployment Definitions allows you to specify the table, record, and a message to record. These are 3 new fields on the form. However, if the Version/Date section is filled in, the user-entered message is prefixed with that information as well.

This is in the current 10.0.8 (beta) under development, so it hasn't yet been released.

The record that's updated (which is, as mentioned, specified in the deployment definition, so your RDK could deploy this record into ANY table with ANY ID) will have the message:

TIMEDATE():" in ":@appid<1>:": ":logMsg

(where logMsg is the user-entered message) appended to the next available field. It is our intent that RDKs from Revelation will update the log record RTI_SYSUPDATES in SYSENV.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

View this thread on the Works forum...