{{tag>category:"None Specified" author:"David McGehee" author:"Gary Hawks - Revelation Software" author:"Aaron Kaplan" author:"akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url]"}} [[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]] ==== Burning Bridges (None Specified) ==== === At 26 OCT 1999 09:12:19AM David McGehee wrote: === This is an E-mail I posted to Rev., yesterday. I have been unsuccessfully trying ALL day to get in touch with tech support. I finally got an operator instead of merely being transferred into oblivion who told me only ONE person was in tech support today as everyone else was in training. As I recall, everyone was in training for a whole week a while back. The virtually total lack of support for the existing products does not bode well for the present, much less the future. Some problems are such that they can wait, but some require Immediate attention as they are crippling or even catastrophic. If nobody is available to even evaluate the problem, the problem can't even be classified much less solved. When a multi-day process suddenly starts hanging up (and locking up the entire application) in a system routine (called F.DISTRIBUTOR) and help is unavailable, it is hard to keep the doors open while waiting around for some pie in the sky new miracle to come along. It is extremely difficult to fight to use a product when product support is totally unavailable - either through lack of people to talk to or because the support people basically say I am not their target market. I have been fighting to get an application up since last Spring and after many, many problems have gotten very close. Almost virtually all of the problems have generated very little practical help from Rev., requiring my time to work out some workaround or solution. I have reported "bugs" as I have found them but I have not received much in return. I am aware that few customers have tables with even 8 million records, much less 30+ million with 75 - 100 million index entries. However, many of the problems I am having are still normal AREV/OI problems, just made more severe or common by the stress of the number of iterations of almost anything. If I can get reasonable support, I can continue to fight to use the product line. However, I have no leg to stand on when I can not even reach a support person, much less receive a workable solution/resolution. I have been using Revelation products since 1985 and I would prefer to continue to do so. Please give me the choice of continuing! David E. McGehee DCS Information Systems (972) 422-3600 (972) 422-3687 (direct) ---- === At 26 OCT 1999 10:03AM Gary Hawks - Revelation Software wrote: === David, Revelation Software has a commitment to our current customers, our future customers, and our employees. The training our support staff is receiving this week reinforces that commitment. Revelation Software has a portfolio of products that satisfy a variety of customers; therefore it is critical we provide opportunities to train our support staff on technologies that will allow them to provide the high level of support our customers expect. I realize the dependence customers have on our support staff, and that is why we have posted a notice about this training on our web site for a couple of weeks. We have requested that non-urgent requests be posted to the web site discussion boards first. Customers with urgent requests may call our customer care department, and they will do their best to get your issue addressed as soon as possible. We did make an effort to contact you yesterday without success, and I appologize for that. If I could make a suggestion, it would be for you to contact myself or someone in Customer Care to arrange a time for one of our support reps to call you, so that we don't continue to get voice mail. I have also escalated your request to our Director of Professional Services and she assured me that someone would be able to get working on this today. As I stated in my voice mail, if you have any information that can be sent via e-mail that would allow a support rep to start working on the issue, please do so. Gary Hawks Revelation Software 978-247-7108 ---- === At 26 OCT 1999 11:28AM David McGehee wrote: === The index node IS resized to a frame of 8k. The symptoms are that the UPDATE_INDEX routine for a certain # of changes which took ~ 30 seconds now just blinks - therefore the index transactions are not actually being updated. AFter processing for a few thousand table record updates, the process hangs (100% cpu & no i/o activity) in a process called F.DISTRIBUTOR. If you abort the process, exit OI and return, a Database Manager process to update the indexes finishes almostly instantly (again I will bet no indexes are being updated). If you start the file update process again, you will get the same problem, just a little further down the pike. The file has nearly 31 million records and has three indexes only at this time: all are Btree, none are Xref - I gave up on that as it takes forever to produce/update such a 75 - 100 Million entry index (with a significant stop list) and most importantly, it takes forever to get the browse list when a couple of common words are requested. ---- === At 26 OCT 1999 11:34AM Aaron Kaplan wrote: === David, I lost this message in context? What are you replying to that makes you bring up the 8K node, or is this just an further explanation? Either way, by 8K node, did you mean frame size? I'd be willing to bet that you have a file with rather large, multi-part keys, about 20+ characters total per key, yes? akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura Group[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] ---- === At 26 OCT 1999 12:15PM David McGehee wrote: === I mentioned the 8k frame size because I had received a voice message stating that I needed to increase the frame size as it made a big difference in performance for large files. The key is a single part key with a nominal and maximum size of 17 characters. The data size varies between 80 and 120 characters - depending upon names, addresses, etc.- with a few going to 150+. The problem developed in an NT Service environment with the file update process being executed on another NT Server machine, only the OI data files were on the NT Service machine. ---- === At 26 OCT 1999 12:40PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote: === Reason I asked was that no matter what you set the frame sizes to, indexing will only work with nodes of a 1K size. This is hard coded into one of the indexing functions. So, as the system tries to redistribute the node, it has to move around huge amounts of records to keep everything in 1K. Since this is being in basic, it sometimes seems like there's no processing being done, or that the workstation isn't doing anything. Not saying this is what's happening, but I know places that are 'hanging' in this program, but it's actually busilly processing, distributing records, and taking 10-20 minutes to add a single record to the index. Simple fix, requires small change to one program (can't remember any longer). The old gold level support would have mailed you an update to the code, don't know what the support policies are these days. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura Group[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] ---- === At 26 OCT 1999 02:00PM David McGehee wrote: === The problem with index frames of 1k is that long before reaching the size of this table (at somewhere around 10 to 1 size ratio between OV & LK) indexing totally dies. I am at about 4 to 1 with 620+ Mb for LK and 2.4 Gb for OV. ---- === At 26 OCT 1999 02:09PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote: === Which frames are we talking about, the frame size in Linear Hash or the index node size? They are completely different values. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura Group[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] ---- === At 26 OCT 1999 02:43PM David McGehee wrote: === "Bang" file frame size. I used the remake_table utility published on the web site. Of course, it had to be modified so the generated file name was legal for an index file name and a couple of other glitches but it reset the frame size of the !file to 8096, just fine. The 8k index file has been working perfectly on several tables up until now. It has a significant speed advantage for most any table size I have encountered; of course, all of my tables are relatively large with the smallest @ ~ 800k records. ---- === At 26 OCT 1999 02:58PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote: === Yeah, that's what I figured. The frame size is different than the node size. If you do a test on the !file, you'll find that each record is only about 1000 bytes. I can't remember is this is just field 4 or if the entire record is limited to about 1000 bytes. What you need is a way to increase that 1000 bytes to something a bit more managable, but unfortunately, only Revelation can do that for you. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura Group[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=BF6D313C7E870FBE8525681600488A14|View this thread on the Works forum...]]