Skip to content

[#27] Change POINTERS back from NUMERIC to INTEGERS

An issue reported by the client documented at YDBOcto#846 (closed) led us to try various ways to fix this.

First, commit fee452c9 was attempted here, as it is directly tied to the issue, but that didn't solve the problem.

Further investigation revealed that the issue has nothing to do with the change attempted in fee452c9, and at its core is an issue with the Octo Postgres emulation; but also, I saw during the investigation that the SSMS was defaulting to 6 decimal points (per the Postgres ODBC driver) for all numeric fields, which is perhaps not the right thing to do. I am sure the issue will have a better fix in the future; for now, the right thing to do is to revert fee452c9, and partially revert a52d81ed (only for POINTER fields, not DATETIME fields). DATETIME fields (currently NUMERIC) will have another solution in the future when YDBOcto#382 (closed) (DATE, TIME) is implemented.

Tested on:

  • SSMS: YDBOcto#846 (closed) is resolved. Rare non integer pointers (.5, .6) show up as zero; pointers that overflow the integer range are shown as the maximum supported integer (2147483647)
  • Squirrel: No change in behavior from before. Non-integer pointers (.5, .6) show up as zero; pointers that overflow the integer range are shown as <ERROR>.
  • VistA DDL Pipeline passes.

Will be sent to our customer for testing prior to merging.

Merge request reports