Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
install vfp3 and insufficient memory 1
- Thread starter infotrak
- Start date
Mike Gagnon
Programmer
Why did you start two threads with the same question?
thread184-750754
Mike Gagnon
If you want to get the best response to a question, please check out FAQ184-2483 first.
- Thread starter
- #3
- Thread starter
- #5
-
1
- #6
Definitely get VFP 8.0 - while there are a few more possible "conversion" problems from 3.0 to than 7.0, you also don't have to worry about the unique 7.0 "features". (The different way of indexing comes to mind! <s>)
You can't really "upgrade" to either since you need VFP 5.0 plus for this ( Also, according to the reworded EULA if you upgrade, then you can't use the old product anymore. (See earlier discussions on this revelation.)
Rick
You can't really "upgrade" to either since you need VFP 5.0 plus for this ( Also, according to the reworded EULA if you upgrade, then you can't use the old product anymore. (See earlier discussions on this revelation.)
Rick
craigsboyd
IS-IT--Management
Rick,
"The different way of indexing comes to mind"
...mind clairfying that statement?
Slighthaze = NULL
craig1442@mchsi.com
"The different way of indexing comes to mind"
...mind clairfying that statement?
Slighthaze = NULL
craig1442@mchsi.com
"Whom computers would destroy, they must first drive mad." - Anon
craigsboyd
IS-IT--Management
Rick,
Hadn't realized that the index files in VFP7 were so much larger than the other versions. When you said "more stable" are you saying that you read something that said the increase in size was to help defend against index corruption? This is all new to me, first I've heard about the indexes being so much different.
Slighthaze = NULL
craig1442@mchsi.com
Hadn't realized that the index files in VFP7 were so much larger than the other versions. When you said "more stable" are you saying that you read something that said the increase in size was to help defend against index corruption? This is all new to me, first I've heard about the indexes being so much different.
Slighthaze = NULL
craig1442@mchsi.com
"Whom computers would destroy, they must first drive mad." - Anon
- Thread starter
- #10
Craig,
Yes, the technique used in VFP 7.0 was meant to introduce more empty spots in the index leaves, so that more records could be added before having to re-balance the tree "limbs". Since there is more exposure to corruption during the rebalancing phase, it was thought that by reducing the number of times this was necessary, it might reduce (one) source of index corruption.
Note: The indexes weren't really different in structure, but in how they were initially filled in and some of the algorithms that did the rebalancing. It was these changes that effected the size of the indexes and some reported that SEEKs were also slower because they required more physical IO's to trace down the deeper links.
Of course the worst case was for those that had very large index files - 1+ gb in VFP 6.0 (and earlier). In 7.0 people were reporting that they were going over the 2gb file limit on the .CDX files. This stopped applications from running when they tried recreating indexes and they ran into this file size limit. Also, in some cases there wasn't enough room on the file servers for all the "new" bloated index files - even when each was below 2gb. e.g. We have one app that has 160+ .CDX files - imagine each one growing 50% to 500% (and more) - that's a lot of disk extra space required, more physical IOs and of course more time to backup!
Rick
Yes, the technique used in VFP 7.0 was meant to introduce more empty spots in the index leaves, so that more records could be added before having to re-balance the tree "limbs". Since there is more exposure to corruption during the rebalancing phase, it was thought that by reducing the number of times this was necessary, it might reduce (one) source of index corruption.
Note: The indexes weren't really different in structure, but in how they were initially filled in and some of the algorithms that did the rebalancing. It was these changes that effected the size of the indexes and some reported that SEEKs were also slower because they required more physical IO's to trace down the deeper links.
Of course the worst case was for those that had very large index files - 1+ gb in VFP 6.0 (and earlier). In 7.0 people were reporting that they were going over the 2gb file limit on the .CDX files. This stopped applications from running when they tried recreating indexes and they ran into this file size limit. Also, in some cases there wasn't enough room on the file servers for all the "new" bloated index files - even when each was below 2gb. e.g. We have one app that has 160+ .CDX files - imagine each one growing 50% to 500% (and more) - that's a lot of disk extra space required, more physical IOs and of course more time to backup!
Rick
craigsboyd
IS-IT--Management
Star worthy explanation, thank you Rick for clarifying.
Slighthaze = NULL
craig1442@mchsi.com
Slighthaze = NULL
craig1442@mchsi.com
"Whom computers would destroy, they must first drive mad." - Anon
- Status
Similar threads
- Locked
- Question
