Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

applying a temporary update to a permanent file

Status
Not open for further replies.

unit512

MIS
Mar 12, 1999
233
US
We are having a problem that requires an innovative solution.<br>
<br>
Using Visual Accountmate we are writing system for a carpet distributor.<br>
<br>
The basic structure is...<br>
<br>
The ITEM FILE has the name of a style and color of carpet<br>
i.e. - Atlantic-0001 (this is a unique item)<br>
<br>
For each Item there are an unlimited number of ROLLS OF CARPET FILE<br>
i.e. Roll # 0001, 0002 etc.<br>
<br>
For each ROLL there are an unlimited number of TRANSACTIONS PER ROLL FILE.<br>
For example, if Roll 0001 has 100 feet of carpet on it<br>
20 feet could be committed for sale to Company A<br>
50 feet were sold to Company B<br>
10 feet are on a sales quote for Company C<br>
5 feet were discarded as damaged<br>
leaving 15 feet on the roll<br>
<br>
When the end user wants to assign X feet to a sales order he or she sees both the summary and detail status of all the rolls under this item.<br>
<br>
The problem is in showing REAL TIME status. We would prefer NOT to update the real databases constantly because if the user assigns 10 feet from roll 1 to an order...and then changes his mind, we need to re update 6 permanent databases.<br>
<br>
So, what we have been doing is building a temporary file, based on the current status. We then have been updating, when the whole order is saved.<br>
<br>
The problem with this approach is two fold...<br>
If I assign 10 feet to roll 0001 ... then create a new line item for the same Item # (same carpet style)...we are not seeing the real status of the roll, since we do not update the permanent file until the order is saved.<br>
<br>
If another user sells the same item, he is not seeing the real time status...and may accidentally over sell the roll.<br>
<br>
What we need is a way to show the real status of each roll, but hold the permanent update until we save the order. My initial thought was to add a field to the roll transaction file. This field would be filled with something like &quot;username&quot;. This record would be included in the<br>
roll status update...because it is a real record in the roll transaction database. When the order is saved, the records for this roll, with this username in the new field would be deleted, and the update would proceed normally.<br>
<br>
However, I am open to suggestion on a better method.<br>
<br>
Glenn
 
I would add the field to the databases and create a new table. <br>
Table - Sales Order Numbers. The sale number field would be unique. There you can keep information about the sale , Name address, status, quote, sale, completed (etc).<br>
<br>
When a record is removed from the Sales Order Number Table the associated records with that Sales Number can be deleted from the main tables.<br>
<br>
If you are using Database Containers you can add the table to the database and make it a table rule. <br>
If not you will have to write a routine that opens all the tables and delete all for sales number = ######<br>
<br>

 
Thanks for the response.<br>
We are working on what you suggested.<br>
With simple transactions its clean.<br>
When 3 users ASSIGN, UNASSIGN and RE ASSIGN without saving, however,<br>
we are still having some problems.<br>
<br>
Glenn
 
If I can be of any other help , contact me<br>
<A HREF="mailto:dave@internationalbid.com">dave@internationalbid.com</A>
 
We have the software to a point, where...as long a user Assigns (adds a record) or unassigns (deletes a record), THAT user sees updated data (i.e. the refresh really reads from the drive)....however,<br>
<br>
If a user just looks at the data, we cannot seem to force a real read from the data file on the drive.<br>
<br>
Is there some sort of 'commit' or 'flush buffer' command in VFP?<br>
<br>
Glenn
 
You did not say if the second user was looking a browse window or a form screen. <br>
<br>
If it is a browse window - Check out the setting of your SET REFRESH COMMAND Change your setting in the program that is first called from the command line / windows that starts the program application.<br>
<br>
If it is a form check out the BufferModeOverride Property of the form.<br>
<br>
<br>
Following is the FoxPro Help on the REFRESH command:<br>
**********************************************************<br>
Determines whether and how often a Browse window is updated with changes made to records by other users on the network.<br>
<br>
Syntax<br>
<br>
SET REFRESH TO nSeconds1 [, nSeconds2]<br>
<br>
Arguments<br>
<br>
TO nSeconds1 [, nSeconds2]<br>
<br>
Specifies whether and how often updates are made. nSeconds1 specifies the number of seconds between updates to a Browse or memo-editing window. nSeconds1 can be a value from 0 to 3,600; the default value is 0 seconds. When nSeconds1 is a nonzero value and other users change records you are viewing, those records are updated when the refresh interval elapses. The records you are viewing aren't updated if nSeconds1 is 0.<br>
<br>
Microsoft Visual FoxPro buffers portions of tables in memory on your workstation. nSeconds2 specifies how often these local data buffers are updated with current data from the network. nSeconds2 is the number of seconds between data buffer updates. You can specify a value between 0 and 3,600; the default value is 5. The buffers are never refreshed if nSeconds2 is set to 0.<br>
<br>
If you specify a value for nSeconds1 other than 0 but don't include nSeconds2, nSeconds2 is set to the same value as nSeconds1. However, nSeconds2 is set to 5 if you specify 0 for nSeconds1 and don't include nSeconds2.<br>
<br>
Performance can be improved by increasing the value of nSeconds2.<br>
<br>
Remarks<br>
<br>
Because tables can be opened for shared use on a network, it is possible that records you are viewing in a Browse window are being edited by other users on the network.<br>
<br>
SET REFRESH affects records displayed in a Browse window opened with BROWSE, CHANGE, or EDIT. Memo fields opened for editing in a Browse window are also updated.<br>
<br>
SET REFRESH can also be used to specify how often data buffered locally on your workstation is updated.<br>

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top