{{tag>category:"OpenInsight 32-bit" author:"Warren Auyong" author:"Bill Caisley" author:"Jared Bratu" author:"Matthew Crozier" author:"Barry Stevens"}}
[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]
==== FS1016 on index (OpenInsight 32-bit) ====
=== At 18 APR 2012 08:30:37PM Warren Auyong wrote: ===
Client out of the blue started getting kicked out of ARev 3.12 with UD4.6 on SBS 2008 workstations on XP Pro 32bit with B114 Maximum number of variables exceeded errors. I tracked this down to index updates on one file. Event log on the server kept listing FS1016 on one !File. If I did a select against the index on that file (set to update on queries) it would tell me the !file wasn't available and to attach it. Clearing the message returned hits. Doing a list/count/verify_lh on the !file immediately after clearing the message showed the !file to be there. I checked the file for non-alphanumeric characters in the index field (simple btree on names). I ran verify_lh on the data/dict/!files. I restarted the UD service, rebuilt the indexes, removed the index and put it back on and would still get the error message on selects. I finally deleted the index and left it off.
What is FS1016? I don't find it in the documentation.
----
=== At 19 APR 2012 04:02AM Bill Caisley wrote: ===
Found in Reverror.dat. FS1016: Record Key too long.
The UD installation manual warns about 'Long Keys' . See document "Netwok Driver Update for Large Keys.
----
=== At 19 APR 2012 09:28AM Jared Bratu wrote: ===
The FS1016 error message is also listed in the 9.3.1 help files under the "REVERROR.DAT file" topic along with the other FS and ENG errors.
Any key over 552 characters is considered to be invalid and attempts to read,write,or delete the record will fail with a FS1016 error.
If you cleared the ! file and the error still appears then I assume the index build or update process is trying to generate a key longer than 552 characters. This may signify a corrupted field since it's unlikely a last name would be anywhere near the limit.
You can perform maintenance on the table if you stop the LinearHash service and disable the REVPARAM file. The client side driver isn't affected by the long key limit - only the service.
----
=== At 23 APR 2012 11:13AM Warren Auyong wrote: ===
Thanks, I thought I had installed the patch for long keys, but perhaps I didn't think it was necessary at the time.
I shall look closer at the data. I did appear to be the same !file record. Last name is just the name of the dictionary column, since it is real estate oriented the last name are often lengthy trusts.
----
=== At 23 APR 2012 07:06PM Matthew Crozier wrote: ===
Have a look at the [url=http://openinsight.wetpaint.com/page/Btree+Index+Structure+and+Stats]Btree Index Structure and Stats[/url] program on the OI Community Source Code site. This utility will check an index structure and show the longest index key found, which may help in determining why an index might be generating large index values. A Btree index on a free text field would be a classic example of that.
HTH, M@
[url=http://www.vernonsystems.com][img]http://www.vernonsystems.com/images/logo_main_ani.gif[/img][/url]
----
=== At 30 APR 2012 01:04AM Barry Stevens wrote: ===
Wow, that's a blast from the past, forgot all about that site. Should be a link here.
Would love a link to all the Google docs source that Bob has posted also. :smile:
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=BA2DB53100041EB6A673FB100|View this thread on the Works forum...]]