Recent content by wreinersmann

No problem. I would definitely try the small Fox App concept. You can write an error trap if the table's in use, so you wouldn't have the copy issue. Good luck

Copying at the same moment could corrupt both the copied AND the original tables. Fox tables are notoriously sensitive.

Without rewriting the Fox App, you can't be sure you won't hit at the same moment. The ideal would be to add a copy function to your Fox App (which it sounds like you can't do)The other thing you could do is write a small Fox App that uses the data SHARED and does the copy or do a SQL to cursor...

Yes, it's a windows file copy. BUT, if you are copying at the same moment someone is copying back to the table, it could corrupt the table. The same moment thing could get you.

Us Fox Guys can be a little sensitive :). If youre using ODBC you won't have any problems with file locking IF the tables are not being used exclusively. IF they are, you will have some file locking issues. To handle locking issues inside of Fox, you set up buffering as appropriate. Most people...

It sounds like the tables are not in a database so you should be able to just copy them. You could also set up ODBC access to the tables from Access. If they hqave access to the original tables, an ODBC connection would eliminate the need to create separate copies of the Fox Tables. The bigger...

You can copy them with a couple caveats. If they are attached to a database (dbc) you can't copy them. They need to be free tables. If you use free tables, however, you are limited to 10 characters for field names. The better solution would be to do SQL calls to copy the data, e.g., SELECT *...

I called Peachtree on a similar problem. They suggested that there is an incompatibility with Peachtree and 2 Windows XP hotfixes. They said to remove HotFixes Q810577 and Q811493. They have not yet fixed the problem in 2004. Removing them does speed up Peachtree slightly, however, there are...