[[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]]
==== 64 megabyte per folder (sub dir.) Limit, any fixes (OpenInsight Specific) ====
=== At 02 MAR 1998 05:03:04PM Bill Buell wrote: ===
{{tag>"OpenInsight Specific"}}
I have a need to deploy a single user desktop applicating in which tables will exceed the current 64 meg. per directory limit. I was told that the NLM would solve this problem, but its not an option in this situation. To the best of my knowledge, I am using the most current release of Opensight (is it 3.5) based on the latest CD I have received as a works subscriber. Any patchs, new releases on the horizon, workarounds, ideas, comments....??? Thanks all.
----
=== At 02 MAR 1998 05:48PM Don Bakke wrote: ===
I'm not certain what limit you are talking about. Can you elaborate (unless someone else knows what this is about)?
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 03 MAR 1998 11:43AM bill buell wrote: ===
Author: Don Bakke
Subject: Re: 64 megabyte per folder (sub dir.) Limit, any fixes
Category: OpenInsight Specific
Author: Don Bakke
Date: 03/02/98
SRP Computer Solutions
I'm not certain what limit you are talking about. Can you elaborate (unless someone else knows what this is about)?
Don - Thanks for responding so quickly, (thats what I LOVE about this website).
To recreate the problem, simple run Openinsignt, open any application, create a folder or subdirectory on you local drive, (or a network drive for that matter), and create an Openinsight native table in that folder (or subdirectory if you will). Now write a little program to count from say 1 to 100000, and using each number as a numeric key, load that table with dummy records (I user rec=@lower.case:"---":@upper.case). You will see that as soon as the total bytes in subdirectory approaches 64 megabytes, that the program will die, and you will not be able to add any more records). Someone at Revtech support acknowledged to us that this is a known problem and that the workaround is to use the NLM server, which will not experitnce any problem with directories containing more than 64 megabytes of total native files.
As i mentioned, i need to deploy an application to a stand alone desktop running Windows 95, so the NLM is not a viable option.
Let me know if you attempt to recreate this situation and find that Openinsight CAN successfully load all 100,000 dummy records. I am hoping that there is some minor change in things which will solve my problem. Thanks all of you, for you ongoing help.
Bill Buell
----
=== At 03 MAR 1998 11:53AM Oystein Reigem wrote: ===
Bill,
Are you sure about this 64 MB limit?
I have a user with more than 80 MB of files in their folder. Or is the limit on net data?
- Oystein -
----
=== At 03 MAR 1998 02:04PM BILL BUELL wrote: ===
Thanks for reponding Oystein. I am very certain about the limit. We first encountered it a month or two ago when we tried to open some linear hash tables from an Arev application. When we tried a set of tables which had been cleared out prior to deployment at a client site, they read just fine, but when we tried to open the same tables filled with data (totalling more than 64 meg in the directory) than we couldnt read tables). I thought perhaps something else was wrong, and I thought that if I created a table from scratch using OpenInsight, on a local drive, with a recent installationg of windows95 ( I just bought a Dell laptop) and the loaded dummy data, that I would rule out any issues of some problem inherent in Arev created tables. Sure enough, the problem repeated its self several times.
But please give me all the circumstances of your user with the 80 meg directories. Are you using the performance pack? What operating System. What workstation level? Whats version of Network operation system?
I would love to be able to deploy a stand alonge desktop application under windows 95 with confidence and handle more than 64 meg of data per directory.
Thanks. Bill Buell
----
=== At 03 MAR 1998 02:59PM Cameron Revelation wrote: ===
Bill,
[i]I have a need to deploy a single user desktop applicating in which tables will exceed the current 64 meg. per directory limit.[/i]
I believe you are referring to the 65535 primary frame limit (aka "the 64k modulo bug") of the 16-bit NPP driver. This would show up when the LH primary file (.lk) exceeded 65535 primary frames, which typically happens at 64mb (64k frames x 1k/frame). This bug was fixed in the NPP 1.5 upgrade, which I believe can be downloaded from this web site for free if you have a license to the NPP 1.4 (which you do if you have OI 3.12 or later).
As far as directory size limits, there are none enforced by OI. We have been attempting to reproduce some customer issues with large LH files using the NPP and to do so we have gigabytes of data in various test directories. I will email you the files if you would like ;-)
I hope this helps,
Cameron Purdy
info@revelation.com
----
=== At 03 MAR 1998 03:17PM Don Bakke wrote: ===
Bill,
Just for the sake of argument I did exactly what you suggested and everything went flawlessly. The only problem is that the overall size of my table was only 17MB even though all 100,000 records using @lower.case:"---":@upper.case were written. When I can afford to let my PC run for a long while I'll increase the loop to 1,000,000.
However, large sub-directories is a normal experience for many applications (at least for AREV). I've never heard of a problem like this so I'm tempted to say it's a specific issue that only you are generating.
FWIW, I performed the above test on a Win95 (original install) P-133, 16 MB, using OI 3.5 and the All Networks Driver 1.4.1.0.
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 04 MAR 1998 04:44AM Oystein Reigem wrote: ===
Bill,
[i]But please give me all the circumstances of your user with the 80 meg directories. Are you using the performance pack? What operating System. What workstation level? Whats version of Network operation system?[/i]
My user has just sent me a copy of the location with all her data tables because she wanted me to check something else for her (search performance on large sets of data). I have replaced my data location with hers, and everything seems to run fine here too. I have successfully tried to add a new row to the largest table. So I'll give you *my* system's specs instead of hers.
I run the old Win95 - not OSR 2. I am connected to a Novell network, but I run the app locally, so I don't think the network is relevant. But if you need to know, the Netware version is 3.11 (upgraded to almost 3.12). I use a single user development OI 3.3 and All Networks Driver (NPP) 1.4.1.0. The user data is not in DATAVOL but in a different, dedicated location.
Here is a dir listing of the data location folder:
Volume in drive C is unlabeled Serial number is 204C:11DA
Directory of c:\oiwg33\regimus\brukdata\*.*
. 18.11.97 14:06
.. 18.11.97 14:06
... ... ...
rev43145.lk 16518144 4.03.98 10:19
rev43145.ov 11664384 24.02.98 17:43
rev43208.lk 80896 4.02.98 11:27
rev43208.ov 423936 4.02.98 11:27
rev43211.lk 161792 13.01.98 9:33
rev43211.ov 438272 13.01.98 9:32
rev43214.lk 269312 4.02.98 14:23
rev43214.ov 1347584 4.02.98 14:23
rev43217.lk 5120 24.02.98 14:45
rev43217.ov 9216 24.02.98 14:45
rev43313.lk 4096 24.02.98 14:49
rev43313.ov 2048 24.02.98 14:49
rev43343.lk 1024 22.04.97 7:38
rev43343.ov 0 28.02.96 9:30
rev43367.lk 5120 24.02.98 14:37
rev43367.ov 7168 24.02.98 14:37
rev43407.lk 57344 25.02.98 11:41
rev43407.ov 40960 25.02.98 11:40
rev43604.lk 4096 16.12.97 9:34
rev43604.ov 6144 24.02.98 14:38
rev44928.lk 1024 29.05.97 20:01
rev44928.ov 1024 23.04.96 12:11
rev44929.lk 2048 4.03.98 10:19
rev44929.ov 2048 23.02.98 13:59
rev45721.lk 10240 10.06.97 12:37
rev45721.ov 16384 10.06.97 12:37
rev45722.lk 2048 10.06.97 13:00
rev45722.ov 7168 10.06.97 12:59
rev45723.lk 20480 10.06.97 13:13
rev45723.ov 28672 10.06.97 13:13
rev45724.lk 17408 10.06.97 13:35
rev45724.ov 18432 10.06.97 13:34
rev45725.lk 6144 10.06.97 14:13
rev45725.ov 7168 10.06.97 14:12
rev45726.lk 5120 10.06.97 14:09
rev45726.ov 10240 10.06.97 14:09
rev45727.lk 20480 10.06.97 14:07
rev45727.ov 17408 10.06.97 14:07
rev46216.lk 2048 24.02.98 14:37
rev46216.ov 7168 24.02.98 14:37
rev46217.lk 290816 24.02.98 14:40
rev46217.ov 445440 24.02.98 14:40
rev46218.lk 474112 24.02.98 14:45
rev46218.ov 707584 24.02.98 14:45
rev46219.lk 259072 24.02.98 14:58
rev46219.ov 430080 24.02.98 14:49
rev46220.lk 19028992 4.03.98 10:21
rev46220.ov 30919680 4.03.98 10:19
revlocks 0 29.05.97 12:21
revmedia.lk 2048 27.02.98 11:41
revmedia.ov 0 29.08.94 11:02
83 807 232 bytes in 51 files and 5 dirs 84 803 584 bytes allocated
73 269 248 bytes free
The rev43145 table is the main table of the app, with 68,535 rows (sorry - it's 68,536 now ). The other crucial data tables (rev43208, rev43211 and rev43214 in some order) have 10,268, 13,786 and 23,965 rows. The rev46220 table is the index of the main table (almost 30 indexes of various kinds). The rev46217-9 tables are the indexes of the other three. There may be garbage among the files, i.e tables that are not attached anymore. But I've accounted for the main bulk.
- Oystein -
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=A402EA235D167221852565BB007921C3|View this thread on the forum...]]