Subject | Re: Error opening database file on Mac OSX |
---|---|
Author | phil_hhn |
Post date | 2004-09-14T06:41:59Z |
Helen Borrie wrote:
and/or OS would matter (I thought you'd only ask it to serve you up
the data file), and it's really up to Firebird to decide how it wants
to structure and use the database inside the file.
So what you're saying is that the way Firebird processes its own
internal data relies on how the platform that you're running on
manages endianness. This need not be the way, i.e you can build an
application that _internally_ processes stuff specifically as big or
little endian, regardless of what is normal on that platform.
Just interested, that's all... as a comparison, from what I recall
about one of the original goals of developing Valentina DB is that the
DB file is entirely portable and is specifically big endian for _all_
platforms (or was it little endian ;-) )
with a different platform...
the FB website for "found 2560, support 10" didn't get me anywhere,
therefore how would this point me in the direction of any particular
topic in the docs??
Thanks once again
P.
> True, it is invalid. You can (but shouldn't) copy a database fileacross
> OS's if they have the same chip architecture; but a Mac is in aworld of
> its own!!the
>
>>What could be wrong? Please don't tell me that the internal database
>>format is different on the Mac vs. the PC (I can't imagine it is).
>
> The internal database format is the same at a higher level but, at the
> level of CPU architecture, the database has to be reconstructed with
> correct endianness and other attributes that are not portable betweenHmmm, that's interesting... I can't see why the CPU and/or achitecture
> incompatible CPU architectures.
and/or OS would matter (I thought you'd only ask it to serve you up
the data file), and it's really up to Firebird to decide how it wants
to structure and use the database inside the file.
So what you're saying is that the way Firebird processes its own
internal data relies on how the platform that you're running on
manages endianness. This need not be the way, i.e you can build an
application that _internally_ processes stuff specifically as big or
little endian, regardless of what is normal on that platform.
Just interested, that's all... as a comparison, from what I recall
about one of the original goals of developing Valentina DB is that the
DB file is entirely portable and is specifically big endian for _all_
platforms (or was it little endian ;-) )
> RTFM!! Never file-copy across platforms, not even across matchingdatabase on
> platforms. Use gbak -b with the -transportable switch to make a backup
> file on the source system and then use gbak -c to recreate the
> the foreign target.Thanks for that, I should have searched for this when we had problems
with a different platform...
>>... and if anyone can tell me what the obscure error "found 2560,... however that's a bit harsh since searching google and specifically
>>support 10" is, please let me know...
>
> It's just Firebird's way of telling you to RTFM.
the FB website for "found 2560, support 10" didn't get me anywhere,
therefore how would this point me in the direction of any particular
topic in the docs??
Thanks once again
P.