 | |
#1
 
| |||
| |||
|
extended files/extensions -
06-05-2006
, 03:30 PM
#2
| |||
| |||
|
|
Hi Btrivieans! this time I wonder about extended files. If the filesize exceeds the maximal filesize of the underlaying file-system, then btrieve automatically devides the file and creates so called extension files. Now the question: when does btrieve decide, wether a special file will need and get extensions? May it be, that ths is decided at create time? The background is: we have a system with several btrieve files, two of them are larger than 2 GB on NTFS. One of them got extension at 2 GB, the other not. File A: 3.6 GB devided in tow parts 2.0 and 1.6 GB File B: 4.1 GB not devided. File A is in btrieve 7.x-format, file B in 6.x format. The server is version 8.6 on a Win 2003 - Server. (it may be, that file A was initial createt on a FAT32-System and copied to the NTFS, as it was new and only some 100 kB long (and dont need extensions yet)). Any hint will be wellcome, thanks in advance! |
is as big as they can get. I suspect you're getting a file size in
1000*1000*1000 GB rather than 1024*1024*1024 GB hence the 4.1GB size.
4 * 1000 * 1000 * 1000 = 4,000,000,000 bytes
4 * 1024 * 1024 * 1024 = 4,294,967,296 bytes
At some stage you'll reach the limit for the file which looks to be
4.29GB then'll an error will occur! You need to convert the file to
version 7 or later.
Version 7 or later files support extensions. Version 7 supports 32 2GB
extensions for a total size of 64GB.
Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk
#3
| |||
| |||
|
|
nmm wrote: Hi Btrivieans! this time I wonder about extended files. If the filesize exceeds the maximal filesize of the underlaying file-system, then btrieve automatically devides the file and creates so called extension files. Now the question: when does btrieve decide, wether a special file will need and get extensions? May it be, that ths is decided at create time? The background is: we have a system with several btrieve files, two of them are larger than 2 GB on NTFS. One of them got extension at 2 GB, the other not. File A: 3.6 GB devided in tow parts 2.0 and 1.6 GB File B: 4.1 GB not devided. File A is in btrieve 7.x-format, file B in 6.x format. The server is version 8.6 on a Win 2003 - Server. (it may be, that file A was initial createt on a FAT32-System and copied to the NTFS, as it was new and only some 100 kB long (and dont need extensions yet)). Any hint will be wellcome, thanks in advance! Btrieve version 6 files (ie file B) don't support segments and 4GB is as big as they can get. I suspect you're getting a file size in 1000*1000*1000 GB rather than 1024*1024*1024 GB hence the 4.1GB size. 4 * 1000 * 1000 * 1000 = 4,000,000,000 bytes 4 * 1024 * 1024 * 1024 = 4,294,967,296 bytes At some stage you'll reach the limit for the file which looks to be 4.29GB then'll an error will occur! You need to convert the file to version 7 or later. Version 7 or later files support extensions. Version 7 supports 32 2GB extensions for a total size of 64GB. Guy Thank you for your hint: of couse you are right: the size is less than |
(archive)-file, that does not change any longer, so we dont need to convert it
at once.
Can you imagine, why the file A is segmented, though it resides on a
NTFS-Filesystem? I guess, that btrieve decides about segmentation at create-time
of the table, right?
regards
Mircea
#4
| |||
| |||
|
|
Guy Dawson schrieb: Thank you for your hint: of couse you are right: the size is less than 4,200,000,000 Bytes. Fortunately the table (file B) is in this projekt a fixed (archive)-file, that does not change any longer, so we dont need to convert it at once. |
Quote:
|
Can you imagine, why the file A is segmented, though it resides on a NTFS-Filesystem? I guess, that btrieve decides about segmentation at create-time of the table, right? |
look at what maximum file sizes were supported by the OSs that P.SQL
would run. Some would support 4GB but others only 2GB. By using 2GB
segments for all OSs they avoided having to write and test code that
supported both 2GB and 4GB files.
Guy
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk
#5
| |||
| |||
|
|
Guy Dawson schrieb: nmm wrote: Hi Btrivieans! this time I wonder about extended files. If the filesize exceeds the >> maximal filesize of the underlaying file-system, then btrieve automatically devides the file and creates so called extension files. Now the question: when does btrieve decide, wether a special file will >> need and get extensions? May it be, that ths is decided at create time? The background is: we have a system with several btrieve files, two of >> them are larger than 2 GB on NTFS. One of them got extension at 2 GB, the other >> not. File A: 3.6 GB devided in tow parts 2.0 and 1.6 GB File B: 4.1 GB not devided. File A is in btrieve 7.x-format, file B in 6.x format. The server is version 8.6 on a Win 2003 - Server. (it may be, that file A was initial createt on a FAT32-System and copied to the NTFS, as it was new and only some 100 kB long (and dont need extensions yet)). Any hint will be wellcome, thanks in advance! Btrieve version 6 files (ie file B) don't support segments and 4GB is as big as they can get. I suspect you're getting a file size in 1000*1000*1000 GB rather than 1024*1024*1024 GB hence the 4.1GB size. 4 * 1000 * 1000 * 1000 = 4,000,000,000 bytes 4 * 1024 * 1024 * 1024 = 4,294,967,296 bytes At some stage you'll reach the limit for the file which looks to be 4.29GB then'll an error will occur! You need to convert the file to version 7 or later. Version 7 or later files support extensions. Version 7 supports 32 2GB extensions for a total size of 64GB. Guy Thank you for your hint: of couse you are right: the size is less than 4,200,000,000 Bytes. Fortunately the table (file B) is in this projekt a fixed (archive)-file, that does not change any longer, so we dont need to convert it at once. Can you imagine, why the file A is segmented, though it resides on a NTFS-Filesystem? I guess, that btrieve decides about segmentation at create-time of the table, right? regards Mircea |
ALL Btrieve 7.x (and 8.x) files are segmented at 2GB boundaries. This
is for maximum compatibility, should you decide to copy the file from
your NTFS system to an OS/2 system (which supports 2GB max).
Pervasive PSQL v9.5 has an option whereby you can avoid the
segmentation, putting the file back in ONE piece, if you have a
large-file file system. (And v9.5 allows you to get a single file to
256GB, in case 64 wasn't enough.)
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - 07/2006 ***
#6
| |||
| |||
|
|
nmm wrote: Guy Dawson schrieb: nmm wrote: Hi Btrivieans! this time I wonder about extended files. If the filesize exceeds the >> maximal filesize of the underlaying file-system, then btrieve automatically devides the file and creates so called extension files. Now the question: when does btrieve decide, wether a special file will >> need and get extensions? May it be, that ths is decided at create time? The background is: we have a system with several btrieve files, two of >> them are larger than 2 GB on NTFS. One of them got extension at 2 GB, the other >> not. File A: 3.6 GB devided in tow parts 2.0 and 1.6 GB File B: 4.1 GB not devided. File A is in btrieve 7.x-format, file B in 6.x format. The server is version 8.6 on a Win 2003 - Server. (it may be, that file A was initial createt on a FAT32-System and copied to the NTFS, as it was new and only some 100 kB long (and dont need extensions yet)). Any hint will be wellcome, thanks in advance! Btrieve version 6 files (ie file B) don't support segments and 4GB is as big as they can get. I suspect you're getting a file size in 1000*1000*1000 GB rather than 1024*1024*1024 GB hence the 4.1GB size. 4 * 1000 * 1000 * 1000 = 4,000,000,000 bytes 4 * 1024 * 1024 * 1024 = 4,294,967,296 bytes At some stage you'll reach the limit for the file which looks to be 4.29GB then'll an error will occur! You need to convert the file to version 7 or later. Version 7 or later files support extensions. Version 7 supports 32 2GB extensions for a total size of 64GB. Guy Thank you for your hint: of couse you are right: the size is less than 4,200,000,000 Bytes. Fortunately the table (file B) is in this projekt a fixed (archive)-file, that does not change any longer, so we dont need to convert it at once. Can you imagine, why the file A is segmented, though it resides on a NTFS-Filesystem? I guess, that btrieve decides about segmentation at create-time of the table, right? regards Mircea ALL Btrieve 7.x (and 8.x) files are segmented at 2GB boundaries. This is for maximum compatibility, should you decide to copy the file from your NTFS system to an OS/2 system (which supports 2GB max). Pervasive PSQL v9.5 has an option whereby you can avoid the segmentation, putting the file back in ONE piece, if you have a large-file file system. (And v9.5 allows you to get a single file to 256GB, in case 64 wasn't enough.) Goldstar Software Inc. Pervasive-based Products, Training & Services Bill Bach BillBach (AT) goldstarsoftware (DOT) com http://www.goldstarsoftware.com *** Chicago: Pervasive Service & Support Class - 07/2006 *** |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.