The first question I have to ask is why are you keeping data in some number of local VFP tables when the MySQL database holds everything? The normal way would be for all stations to simply access the MySQL database. That should solve your problem.
John.


>Hello, folks.
>
>Currently, we have a client/server app. that's being used for logistics
>tracking and dispatch. Each client has it's own local (127.0.0.1) VFP database
>that they update when an order/shipment comes into the office. During this
>process, the client also updates an intranet-based MySQL database that's
>a table-structure clone of the VFP client.
>
>
>The problem that we're having is that when one of the clients takes in
>a new order/shipment and updates its local-host VFP database, the
>other clients don't get to see this update. That is, the client code updates
>locally, updates the MySQL database on the server, and then goes about
>its business, waiting for a new shipment/order.
>
>
>So, I guess my question is this: when a new shipment/order comes in,
>would it be faster and easier to update the other VFP clients directly
>and then tell them to re-read their tables, updating their displays,
>or should we use some form of stored procedure on the MySQL server
>and update the VFP clients via ODBC? Also, what kinda pitfalls are
>we looking at with either solution?
>
>
>
>BTW, we do realize that the stored-procedure update will be kind of
>slow; however, this app is intranet based on a gigabit ethernet network,
>so "slow" will probably be somewhat relative :^). Also note that this
>is an "in-house" app. only and will never see use outside of our
>company.
>
>
>Any help here will be appreciated and TIA!
>
>Randall