🚀 go-pugleaf

It was really simpler than
I thought. Now my application can read/write to a
160GB file now (at least)!

I did a lot of coding doing my own file io routines on an
application I wrote many years ago before I know a hint
about SQL (my/ms/oracle).

The reporting is based on flat files.
And folks still use it today.

Just have to move everything to a RDBMS now
or at least have this as an option for
the SQL savvy user.


Thanks for all the responses.

Colin B Maharaj
Full time developer
php/xhtml/c++/javascript/css/cshell
Trinidad, West Indies


[ I Liberated myself from the ]
[ Telecoms company I once worked ]

Remy Lebeau (TeamB) wrote:
> "Colin B Maharaj" <noreply@myhost.com> wrote in message
> news:46443D35.2050709@myhost.com...
> 
>> Does the FileWrite routine writes pass 2 or 4 GIGs
> 
> Yes.
> 
>> nowhere do I see that FileWrite is 64 bit based?
> 
> It doesn't need to be, because it doesn't deal with file offsets
> directly, so it doesn't care whether the current offset is past 2GB or
> not.
> 
>> Similarly does the FileRead routine work pass the 2 or 4 GIGs point?
> 
> Yes.
> 
>> It is clear that FileSeek is both 64 and 32 bit based. So
>> doe it mean that most of my recoding will be based on
>> using a 64 bit file pointer for seek operations and thats it!! (?)
> 
> File pointers have always been 64-bit at the OS level.
> SetFilePointer() has supported 64-bit file sizes for many years now.
> FileSeek(), however, did not utilize the higher 32 bits until BCB6.
> 
> 
> Gambit
> 
>