It is not clear to me whether you are using JET 3.5 or JET 4.0. Indeed JET
Many thanks for your comprehensive reply.
Sorry, I got confused - it is Access 97, JET 3.5
3.5, native to Access 97, has a 1 GB limit. Access 2000/2002/2003, which all
use JET 4.0, has a 2 GB limit. However, due to the introduction of Unicode in
JET 4, you cannot expect to store double the amount of data vs. a JET 3.5x
database.
Indeed. Some time ago I did some tests with the later version of my
DejaVu software, and the same amount of data seemed to take up about
twice the space!
What exactly are you importing? From the hyperlink you provided, I read the
following: "Yesterday I imported a fairly large TM provided by a client,
...". Is TM a Training Manual? Or possibly Translation Memory, whatever that
is, ie. "My main translation memory software".
Thanks for reading the message in the link I provided. Yes, the context
is Translation Memory software/databases.
In this particular case the format of the Translation Memory file I
Does this involve an OLE Object data type? If so, perhaps you should be
linking to the file, instead of attempting to import it. There are also more
efficient methods available of importing this data instead of relying on OLE
embedding technology, which is the only thing you get when using the user
interface to import.
I'm not familiar with OLE, sorry. In any case, regarding import methods
I think I am limited to using what is offered by my DejaVu software.
I hope you have a good back-up copy! You could very easily end up with a
corrupted database. I do not recommend testing fate like this.
Yes, unfortunately I have some experience with database corruption, and
I do have a backup strategy (although it is not as robust as it
could/should be!)
Talking about database corruption, is it really true that the only way
of verifying the integrity of a database is to try and compact and
repair it and watch for errors??? See
I also read about how it was suggested that you create a netlogon.bat file
with a command to determine the file size. Have you tried using the built-in
FileLen function in Access? I'm not sure if it is available in Access 97 or
2000, but it is certainly present in Access 2002. From the Immediate Window,
you can issue the following command:
?FileLen(Currentdb.Name)
Thus, it seems to me that you could use this function, if it is available in
your version of Access, in a startup routine to test the file size, instead
of just relying on a test each time you log on.
The netlogon.bat routine suggested by Pegasus in
microsoft.public.win2000.general a while back works very well for me,
but thanks for the suggestion.
However, I'm not familiar with the "Immediate Window" and I don't know
whether it is available in Access 97. In any case, I'm not using Access
97 directly, i.e. while the DejaVu database format is based on Access
97, I'm not sure I could modify my DejaVu databases manually to
introduce the FileLen command. In any case, unless I am missing
something, in practice there probably wouldn't be that much difference
to the netlogon.bat routine, because I usually start DejaVu as soon as I
log on and then have it running more or less all day.
What about the possibility of linking to one or more external databases?
Perhaps you can spread some of the data amongst one or more linked tables, in
separate databases. You've also got the free SQL Server Express edition
The later version of DejaVu does indeed offer the option of 2 databases,
and there is also a more expensive "Workgroup" edition that offers scope
for up to 5 databases, I think.
However, for the time being I am limited to the older version of DejaVu
for a number of reasons.
available, which has a higher capacity (I'm not positive, but I think it
might be 4 GB). Or use a MySQL BE, or....
Sounds good, but again, as far as I am aware I am limited to the
database manipulation options available within DejaVu, i.e. I don't
think I could use external database manipulation software, although I
would, of course, be pleased to be told otherwise
Regards
Herbert Eppel
