This information may not be current, but I seem to remember hearing some
really nasty stories about people putting MySQL data dirs on NFS
exports. I would research the appropriate documentation before
attempting such a configuration.
-Original Message-
From: mysql-digest-help
Once you moved the files, did you check the ownership and permissions?
I have had the same error after restoring databases from a backup, only
to find the files were owned by root and the permissions were munched.
Something that I have been known to do is to add another, larger disk
drive,
Your english is understandable so please don't apologize.
The way Access/ODBC works during a 'find' operation is that Access will
ask the MySQL Server for each record, one at a time, until it finds a
match. This is very resource intensive and I try very hard to avoid
finding records in this
I would be very intested in finding out more about the hardware being
used here, as well as load on the server (queries/sec, etc.), and maybe
the amount of data (Megabytes, Gigabytes, Terabytes). Twenty million
records is a lot but that number in itself may not give the application
the
I am going to assume that you are on a windows platform and tell you
about what I did. I developed a large ERP system using MSAccess for
the front end and MySQL for the backend. Because MSAccess doesn't
notice changes to the table structure of a MySQL (ODBC) table, I wrote
a routine that
If its a hosting PROVIDER, the table locking issue should really only
be a factor for your database. If your design is good, then the rest
shouldn't matter.
Machine memory and processing power are another issue entirely. Other
users could drag the machine down with poor design issues. One
Verify that you have a primary key and a DateTime Stamp field for your
table.
I do this with a Serial field {Serial int(11) not null Primary Key
auto_increment} as the first field and {DateChanged (TimeStamp)} as the
second field for each table that I intend on accessing from MSAccess.
