Messages
Reply
Edit
Delete
Well, I suppose at this point its a choice of where you want your pain, not whether you have it or not.
If you're able to get VFP to interact with MySql then I'd recommend taking that approach. Read Rick's topic 'Configuring Web Connection for use with SQL Server' in the help file. In there he notes, "wwSQL class wraps SQL Passthrough for error handling and connection management Web Connection also includes a wwSQL class which is a wrapper around SQL Passthrough that works for any ODBC connection." so I'd wager you might be able to slipstream a (relatively) minor change to adapt the log files as needed.
Regards,
Doug
The setup is IIS with com based vfp exe's using either dbf or mysql based on the config of the server or 'store'. We've created a SAAS eCommerce platform using WWWC as the engine. We run anywhere from 10-500 eStores on a Windows box. The table that is giving us trouble is the primary 'stores' table that houses all the info about each well ... store. So on the server that is having trouble there are about 300 store records. lots of memo fields in each record. We DO have a mysql version that we can upsize to but as I wrote previously sort of stinks that we have to do that. We've had this setup for 14 years now and while this is in fact our largest store table, it is still not enough to cause this much pain I would have thought.
MB,
Question: If some of your apps use MySql and others do not, does that indicate that you have been able to get Web Connect code to talk with MySql? If so then all you'd need to do is 'point' the framework to a MySql instance of the log files? You're using the Windows version of MySql, correct?
If you don't mind my asking what is the primary program you use written it? I'm a little unclear of your setup.
Maybe wwwDotNetBridge?
Anyway, I have to think you can resolve this long term. I'd sure get tired of having to flip files every few days. *s*
Regards,
Doug
Thanks Doug. We actually have a MySql version of our app but still like to use the vfp tables on some installs. We chose MySql to make it seem like we were not biased to win only stuff. Sort of wish we used MSFT Sql, but C'est la vie.
Out of curiosity are you using Rick's tools for WWWC or .net?
Hi MB,
As Rick suggested this is an issue of the way Foxpro manages the memo file. Any change precipitates a new entry and an internal redirect in the header to the new location inside of the memo field where the old (and same as you suggested) now resides.
Here are three specific approaches.
1. Upsize to SQL if possible
2. Put up away page
Start VFP
use TheFile EXCLUSIVE
COPY TO TempFileName with production
CLOSE ALL
RENAME [orignnal table name] to Some other temp name (same for FPT file)
RENAME TempFileName to [original table name] (same for FPT file)
restart system
take down away page (or use Rick's built-in stuff)
3. Put up away page
USE [original table name]
PACK MEMO
PACK
CLOSE ALL
restart system
take down away page (or use Rick's built-in stuff)
Of the three I'd recommend #1 every time if at all possible. It's the best long-term approach. The next choice would probably be #2 as it's quicker to copy the actual file versus waiting for VFP to PACK a large file ( typically - YMMV depending on hardware etc) When VFP copies a memo file it doesn't copy the now-unused portions.
Regards,
Doug
After almost 25 years of dbf coding I am pretty surprised I am posting this question, but here goes. Why is the fpt of system dbf growing to 2g very 4-5 days? We do not store images in any of the fields, just text. The number of records is not changing. After packing the table the dbc cdx and fpt might be all of 9meg. Then a few days goes by, app crashes and reason is the table is 2gig.
Any ideas?
ps: the app is a west wind app we created.
