On Sat, 16 Jan 2010, David Arturo Macias Corona wrote: > >I have not found a clear answer > >Everyone have his own impression :-) > >What is file size limit in DBF format ? > >and in DBF-(x)Harbour ? > >and in DBF-ADS 6.2x ?
In the past I was answering for such questions over 10 times. You may find these messages in the Harbour and xHarbour mailing list archives. A short description I added also to tests/xhb-diff.txt I do not know ADS details so I do not it's limitations. For sure it does not support all Harbour extenssions so they are smaller and for sure there is nothing in ADS what exceed Harbour any limits for DBFs and related files (memos and indexes) so migration to ADS without changing the format to ADT+ADM+ADI can only reduce the maximum supported file size or in some cases leave them on the same level. If someone claims sth different then he simply does not know what he's talking about and you can ignore him. If you need bigger files then you have to switch to different format. Each program which uses OS files is limited by OS API. The exact limitations can be found in the OS documentation and they depends on the operating system internals (OS kernel) and used file system (FS). Additionally please remember that locking schemes can seriously reduce maximum file size. On some systems it's not possible to read from locked area. In such case you have to switch all your applications accessing the files to locking scheme which do not cause such limitations, i.e. use Harbour 64bit locking. [...] > As we have: > 1) DBF files larger than 2 Gb do not fail > 2) Record pointer movement does not fail in these files, including DBSEEK() > 3) APPEND FROM / record pointer movement does not fail Right conclusion. > 4) Users confirm these kind of errors happen crossing 2 Gb, > for example Fred Seyffert: > ======================== > I'm having the continuation of a long term problem with large data file > (>2gb) read errors. Mostly I get 1010's from standard errorblock trapping, > but sometimes get They use non POSIX system i.e. DOS or WINDOWS with VFP locking scheme in which the RLOCK and FLOCK are is at range 0x6E6B27FF : 0x7FFFFFFE. In such systems read/write access from locked region is blocked by OS if client is not lock owner so the above error appear when other station [R|F]locked some records in DBF file and user program wants to read records which are located in the above range. That's all. It's expected behavior. They should read about locking schemes and switch to other locking scheme which do not cause such limitation. > ------------------------------------------------------------------------ > Application Internal Error -app.exe > Terminated at: 2010.01.15 12:39:02 > Unrecoverable error 9201: hb_cdxPageSeekKey: wrong parent key. > Called from DBSEEK(0) > [...] And this is result of file corruption, i.e. due to wrong CPs or server/ client computer crash and FS corruption. > Perhaps some kind of memory corruption, limits in some functions ( > DBSEEK(), DBGOTO(), ... ) dealing with values greater than 2**31 > under certain circunstances ? Compiler issues ? I've never heard about such limits in code I created. All limits are result of used file structures and external limitations like used OS or FS. Harbour does not introduce any own limits. Anyhow if you will find sth then I'm very interesting. For sure it will be fixed immediately. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
