One of my tables just broke. Really, really broke. (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== One of my tables just broke. Really, really broke. (AREV Specific) ====
=== At 26 JUL 1999 10:00:32AM Mats Gefvert wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
Hi...



A user just called me and reported a GFE in one of our biggie tables (20+ MB). I thought, ok, an index broke (which might happen now and then for some reason), but I'll just go ahead and fix it, since I've done it before.



To start with, VERIFYLH crashed as it was about to display the results. Oh well, I do a list of SYSLHGROUPS by myself and find out that 64 groups are faulty. Step into DUMPLH and see nothing but ... blank data. All groups from 10177 to 10241 are blank. Just blank.



I kind of feel like that Star Trek movie (was it Generations?) when that Nexus thing ripped a part of USS Enterprise away into oblivion, taking Captain Kirk with it (who would, for now, represent the customers that were stored in group 10177 to 10241).



I've been through this before though (and for this reason we have double backups of everything). This time it's easier, since the customer table doesn't link to so many others. It was worse when Nexus sliced a couple of groups away from my account table. Don't want that to happen again.



But... did I do something wrong? Like, tempting gods or wear an illegally-colored tie or so? Thank God we're switching to Informix soon, but I'd just like to survive until then... *smile*



Anyway, here goes the stuff: We're a Windows 98/Novell Netware 4.11 network with Advanced Revelation 3.12 utilizing the NLM 1.12 (I think ... could be 1.10).



Looking through our configuration I just found out, however, that TURBODIS.NLM is *not* loaded, and TTS *is* enabled. We threw out our SFTIII server connection a while ago, and I figure that system engineer must have not known about the special requirements of the NLM when he configured the new server... Could that have done it? I don't seem to find the special characteristics of the turbo-fat bug around, though, so I don't think it's that, but still...?



Well. Gotta go get some coffee and start working, I guess. Maybe some day I'll write a book about it.



Regards,

Mats Gefvert 
</QUOTE>
----

=== At 26 JUL 1999 12:31PM Tony Marler @ Prosolve Software wrote:  ===

<QUOTE>Mats



As well as getting the Novell box configured correctly ensure that the users are all actually using the NLM by ServerOnly=1 in the Revparam files.



This will prevent new GFEs but even after the restore from a good backup you need to run VERIFYLH to ensure no potential GFEs already in the application before going live again. Do this in single user mode with NLM turned off and driver changed to old netware or single user driver to be safe.



Tony

</QUOTE>

----

=== At 26 JUL 1999 12:32PM Warren wrote:  ===

<QUOTE>]Anyway, here goes the stuff: We're a Windows 98/Novell Netware 4.11 ]network with Advanced Revelation 3.12 utilizing the NLM 1.12 (I think ]... could be 1.10).



Isn't v1.5 the current version. Upgrade.





]Looking through our configuration I just found out, however, that ]TURBODIS.NLM is *not* loaded, and TTS *is* enabled. We threw out our ]SFTIII server connection a while ago, and I figure that system ]engineer must have not known about the special requirements of the ]NLM when he configured the new server... Could that have done it? I ]don't seem to find the special characteristics of the turbo-fat bug ]around, though, so I don't think it's that, but still...?



This is you problem right here. Never ever run TTS on ARev file directories...Never ever. And the TURBODIS.NLM is a must when using the NLM. Whenever a Novell server running ARev is upgraded or changed always...repeat always...inform the powers-that-be of the requirements : No TTS and TURBODIS.NLM in writing to CYA.

</QUOTE>

----

=== At 26 JUL 1999 10:35PM garygnu@compuserve.com wrote:  ===

<QUOTE>Well, now you know why GFE stands for Gone For Ever.  Besides, I'm sure you'll be really happy with Informix .   Moving to the Nexus might not be a bad idea.  That Lexus/Nexus research thing is one heck of a database.  If not, I'm sure it's a nice ride to where ever you'll end up.







garygnu@compuserve.com

[img]http://ourworld.compuserve.com/homepages/garygnu/graphics/gnu-head-sm.jpg[/img]

</QUOTE>

----

=== At 26 JUL 1999 10:38PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:  ===

<QUOTE>Blanks will happen depending on the GFE.  Sometimes you get some really weird looking things, like bit-shift right thingies.



These things happen when the header has more groups than really exist.  In this case, I'd bet turbofat or TTS thing.  Hard to say which one, though my money's on the turbofat.  TTS problems would probably scamble much more of the file than what you have.





akaplan@sprezzatura.com

[url=http://www.sprezzatura.com]Sprezzatura Group[/url]

[img]http://www.sprezzatura.com/zz.jpg[/img]



</QUOTE>

----

=== At 27 JUL 1999 02:20AM Eric Emu wrote:  ===

<QUOTE>Lexus, Nexus, and then Hexus.....



Out-takes include the famous (cut) last words of Kirk...



"The bridge is on the Captain...."

</QUOTE>

----

=== At 28 JUL 1999 08:07AM garygnu@compuserve.com wrote:  ===

<QUOTE>Well, at least we can get him to stop talking about his log.



garygnu@compuserve.com

[img]http://ourworld.compuserve.com/homepages/garygnu/graphics/gnu-head-sm.jpg[/img]

</QUOTE>

----

=== At 29 JUL 1999 09:38AM Don Miller - C3 Inc. wrote:  ===

<QUOTE>Re: TURBODIS.NLM / FATFIX (Ver 3.x)

This problem was originally reported by users of B-Trieve software.  The TURBO FAT filing system under Netware gets corrupted in largish files that are randomly accessed and extended.  You can see it happen if you NCOPY a file to a junk directory.  The file will get truncated. The DOS XCOPY or COPY command won't do this.  The patch is generically known as TURBOD and has versions for 4.0 and 4.1x.  It is a must if you're using the NLM.



Don Miller

C3 Inc.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=ABA3CBD98A56E35B852567BA004CF40C|View this thread on the  forum...]]