As I mentioned in CDP, this has nothing to do with D3 but it's always fun to blame D3 for whatever ails ya. David is using the %functions from BASIC which are wrappers around raw C functions. The limitations of these functions are that of the OS, not the DBMS wrappers. A quick Google for "fopen 2gb" will show tons of postings on this topic from non-MV developers. My posting to CDP also asked about the main reason for taking this technical approach so that someone can provide a better approach to solving the problem, but the last time I asked "why" here I lost a bit of my backside. I've also posted a note on David's behalf to the TigerLogic D3 Linux forum to ask if the %functions allow for a complete passthru to the OS. If so then he may be able to make use of 64bit (or Long) functions that are available to C developers but not in the current D3 documentation.
Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com > From: Martin Phillips > I'm not quite sure why I would want to read/write a > sequential file over 2Gb but, given that this > originated as a D3 comment and has found its way on to > the U2 site, let me just add that QM can handle > sequential files over 2Gb. > > The argument used by UV is that because integer values > are stored as 32 bit numbers internally, file > addresses over 2Gb cause a problem. A 64 bit version > of UV still stores integer values as 32 bits because > to do otherwise would potentially impact some > applications (think about bitwise operations, for > example). > > Also remember that at the operating system level, 64 > bit file addressing does not require a 64 bit > architecture, just use of long long int variables or, > in some cases, a pair of 32 bit variables. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
