Re: DBF Synchronization

2012-05-09 Thread Thierry Nivelet
If you installed FoxInCloud Adaptation Assistant, you've got a free DBC 
/DBF synchronization class

See VFP9\Tools\ab\abData.prg:
DEFINE CLASS abDataSyncVFP AS Custom

relies on a timestamp field to be defined in property .cTimeStampField

Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/



Le 07/05/12 15:28, Jeff Johnson a écrit :
 Excuse me if this was recently discussed because I thought it was, but
 couldn't find it.  I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization.

 I have looked at DBFSync but it requires selecting each dbf and each
 field to synchronize.  I suppose once you set it up, that would be okay.

 Does anyone use synchronization effectively in their applications?

 TIA


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4faa2f82.9080...@foxincloud.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-09 Thread Thierry Nivelet
precision:
you need to install FAA *and* adapt your application to FiC
or install FoxInCloud Application Server, trial edition

both softwares are free to use.

Thierry Nivelet
FoxInCloud
Give your VFP app a second life in the cloud
http://foxincloud.com/



Le 09/05/12 10:49, Thierry Nivelet a écrit :
 If you installed FoxInCloud Adaptation Assistant, you've got a free DBC
 /DBF synchronization class

 SeeVFP9\Tools\ab\abData.prg:
 DEFINE CLASS abDataSyncVFP AS Custom

 relies on a timestamp field to be defined in property .cTimeStampField

 Thierry Nivelet
 FoxInCloud
 Give your VFP app a second life in the cloud
 http://foxincloud.com/



 Le 07/05/12 15:28, Jeff Johnson a écrit :
 Excuse me if this was recently discussed because I thought it was, but
 couldn't find it.  I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization.

 I have looked at DBFSync but it requires selecting each dbf and each
 field to synchronize.  I suppose once you set it up, that would be okay.

 Does anyone use synchronization effectively in their applications?

 TIA

[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4faaa893.2080...@foxincloud.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: Re: DBF Synchronization

2012-05-08 Thread AndyD
I looked at in some depth a few years ago and as far as I can remember 
the main problem was lack of decent documentation, I didn't use it in 
anger because in the end I convinced the user to move the backend to SQL 
Server and wrote a small fairly limited web app for the remote users.
AndyD 8-)₹

On 08/05/2012 06:03, MB Software Solutions, LLC wrote:
 On 5/7/2012 1:40 PM, AndyD wrote:
 offline views?
 I saw that in VFP Help years ago but I thought I had heard somewhere
 that they didn't work as well as you might think?



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/4fa8e7d3.2070...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: DBF Synchronization

2012-05-08 Thread Paul McNett
On 5/7/12 2:39 PM, MB Software Solutions, LLC wrote:
 Good points, but begs the question:  is this a 1-way synch or 2-way?  In
 other words, are changes on the laptop only going to the server, or is
 it possible for server changes to be newer than the laptop and thus you
 go that direction (from server to laptop db)?  If you have the date/time
 stamping like Stephen said, it helps make this possible.

I have five things to offer as requirements for true 2-way synchronization 
between 
any number of clients:

1) all timestamps stored in UTC (duh).
2) all clients sync with ntp server regularly to avoid time drift
3) UUID primary keys generated on the client side
4) transaction log kept on server and on client for use in the 2-way sync
5) syncing a client to a server should block other clients from syncing at the 
same time

Paul

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa96531.7020...@ulmcnett.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: DBF Synchronization

2012-05-08 Thread José Enrique Llopis
I agree with in the first 4 points

¿Why you cannot sync more than one client at the same time?

Yes, it's very complex

Pepe Llopis


-Mensaje original-
De: profox-boun...@leafe.com [mailto:profox-boun...@leafe.com] En nombre de
Paul McNett
Enviado el: martes, 08 de mayo de 2012 20:26
Para: profox@leafe.com
Asunto: Re: DBF Synchronization

On 5/7/12 2:39 PM, MB Software Solutions, LLC wrote:
 Good points, but begs the question:  is this a 1-way synch or 2-way?  In
 other words, are changes on the laptop only going to the server, or is
 it possible for server changes to be newer than the laptop and thus you
 go that direction (from server to laptop db)?  If you have the date/time
 stamping like Stephen said, it helps make this possible.

I have five things to offer as requirements for true 2-way synchronization
between 
any number of clients:

1) all timestamps stored in UTC (duh).
2) all clients sync with ntp server regularly to avoid time drift
3) UUID primary keys generated on the client side
4) transaction log kept on server and on client for use in the 2-way sync
5) syncing a client to a server should block other clients from syncing at
the same time

Paul

[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/2940CAD843CD42E9ADE3ED7F1F6B040C@LENOVO1
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread Stephen Russell
On Tue, May 8, 2012 at 1:25 PM, Paul McNett p...@ulmcnett.com wrote:
 On 5/7/12 2:39 PM, MB Software Solutions, LLC wrote:
 Good points, but begs the question:  is this a 1-way synch or 2-way?  In
 other words, are changes on the laptop only going to the server, or is
 it possible for server changes to be newer than the laptop and thus you
 go that direction (from server to laptop db)?  If you have the date/time
 stamping like Stephen said, it helps make this possible.

 I have five things to offer as requirements for true 2-way synchronization 
 between
 any number of clients:
---
 1) all timestamps stored in UTC (duh).

#1 mistake I have seen is this one!


 5) syncing a client to a server should block other clients from syncing at 
 the same time

 Not sure about only one at a time.  Makes Monday morning a bitch when
the sales team is all present.


-- 
Stephen Russell
Sr. Analyst
Ring Container Technology
Oakland TN

901.246-0159 cell

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/CAJidMY+tOHHY-70mbPGpVfkj-GFpHpWeq0LyE8_yLHgKFVt=h...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread Paul McNett
On 5/8/12 1:02 PM, Stephen Russell wrote:

   5) syncing a client to a server should block other clients from syncing 
  at the same time
   Not sure about only one at a time.  Makes Monday morning a bitch when
 the sales team is all present.

I guess that isn't really a hard requirement, but it sure makes reliable 
syncing a 
lot harder to implement.

Paul

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa97f2d.1080...@ulmcnett.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread MB Software Solutions, LLC
On 5/8/2012 4:02 PM, Stephen Russell wrote:
 5) syncing a client to a server should block other clients from syncing at 
 the same time

   Not sure about only one at a time.  Makes Monday morning a bitch when
 the sales team is all present.


Salesman #1 updates Acme Company customer records.  So does Salesman #2. 
  Who's update sticks?  Is it last change in ?  (Devil's advocate)


-- 
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa97f32.9070...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread Paul McNett
On 5/8/12 1:16 PM, MB Software Solutions, LLC wrote:
 On 5/8/2012 4:02 PM, Stephen Russell wrote:
   5) syncing a client to a server should block other clients from syncing 
  at the same time
 
  Not sure about only one at a time.  Makes Monday morning a bitch when
   the sales team is all present.

 Salesman #1 updates Acme Company customer records.  So does Salesman #2.
Who's update sticks?  Is it last change in ?  (Devil's advocate)

I guess the rule should be whoever's update happened chronologically after the 
other 
(remember everyone is time synced).

But then you have the possibility of one salesperson thinking that their update 
stuck 
(because he or she sync'd first). No big deal, since chronological is how it 
usually 
works anyway.

Paul


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa98017.8050...@ulmcnett.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread MB Software Solutions, LLC
On 5/8/2012 4:20 PM, Paul McNett wrote:
 On 5/8/12 1:16 PM, MB Software Solutions, LLC wrote:
 On 5/8/2012 4:02 PM, Stephen Russell wrote:
   5) syncing a client to a server should block other clients from 
 syncing at the same time

  Not sure about only one at a time.  Makes Monday morning a bitch when
   the sales team is all present.

 Salesman #1 updates Acme Company customer records.  So does Salesman #2.
 Who's update sticks?  Is it last change in ?  (Devil's advocate)

 I guess the rule should be whoever's update happened chronologically after 
 the other
 (remember everyone is time synced).

 But then you have the possibility of one salesperson thinking that their 
 update stuck
 (because he or she sync'd first). No big deal, since chronological is how it 
 usually
 works anyway.

Right.  There's no real way to avoid a mistaken update in this situation 
without extensive coding.


-- 
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa9814b.20...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-08 Thread Rafael Copquin
But the thing is, why should one salesperson step on the toes of another 
salesperson? I mean, the ACME Co should be served by one person, because 
it is located in the geographical area assigned to her/him by 
management. Another salesperson would be assigned another co and so on. 
Unless, clients's branches are in many areas. This is a management 
issue, in my view. All we programmers can do is follow the company rules 
and adapt our routines accordingly.

But the basics of synchronization as described here by a few of us 
should be the way to go. Then you can adapt for the different situations.

Rafael Copquin


El 08/05/2012 05:25 p.m., MB Software Solutions, LLC escribió:
 On 5/8/2012 4:20 PM, Paul McNett wrote:
 On 5/8/12 1:16 PM, MB Software Solutions, LLC wrote:
 On 5/8/2012 4:02 PM, Stephen Russell wrote:
5) syncing a client to a server should block other clients from 
 syncing at the same time
   Not sure about only one at a time.  Makes Monday morning a bitch 
 when
the sales team is all present.
 Salesman #1 updates Acme Company customer records.  So does Salesman #2.
  Who's update sticks?  Is it last change in ?  (Devil's advocate)
 I guess the rule should be whoever's update happened chronologically after 
 the other
 (remember everyone is time synced).

 But then you have the possibility of one salesperson thinking that their 
 update stuck
 (because he or she sync'd first). No big deal, since chronological is how it 
 usually
 works anyway.
 Right.  There's no real way to avoid a mistaken update in this situation
 without extensive coding.



___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa9a26a.4070...@fibertel.com.ar
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-07 Thread Stephen Russell
On Mon, May 7, 2012 at 8:28 AM, Jeff Johnson j...@san-dc.com wrote:
 Excuse me if this was recently discussed because I thought it was, but
 couldn't find it.  I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization.

 I have looked at DBFSync but it requires selecting each dbf and each
 field to synchronize.  I suppose once you set it up, that would be okay.

 Does anyone use synchronization effectively in their applications?
--

Do you have a datetime column for a row change?  If so you just have
to update dataB with dataA values when they are not the same.

If you do not have something like this how are you going to know which
one is recent?

-- 
Stephen Russell
Sr. Analyst
Ring Container Technology
Oakland TN

901.246-0159 cell

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/cajidmykb+jvro4v5v_x4s1pgv4zlqsv_qwvtdm7uu14bz-i...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-07 Thread Kevin Cully
It'd really help if you used UUIDs (GUIDs) as the primary keys as well.

SYS(2015) is the VFP poor-man's UUID function (emphasis on poor) but I'd 
recommend getting one of the UUID functions in case record creation 
grows to many per second or more.

On 05/07/2012 10:54 AM, Stephen Russell wrote:
 Do you have a datetime column for a row change? If so you just have to 
 update dataB with dataA values when they are not the same. If you do 
 not have something like this how are you going to know which one is 
 recent? 

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa7e3af.4080...@cullytechnologies.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: DBF Synchronization

2012-05-07 Thread José Enrique Llopis

I have on a project a Journal table where i write the modifications

Just send the journal to another system and recover it to replicate all the
changes made on the first computer.




I have on every table to sync a field named  SYNCTAG C(12) with the
DefaultValue  versynccode(TABLENAME)  The default value is SYS(2015)



The table, on the description field has the following text:

TITLE=TABLENAME
SHARED=YES/NO
KEYFIELD=KEYFIELDS


And on the triggers field:

Insert trigger:   jrn(tablename,1)
Update trigger: jrn(tablename,2)
Delete trigger: jrn(tablename,3)


Code to write the changes on the journal table and to recover it on a
different machine:



***
*** Writes modifications en the journal table
***
FUNCTION JRN
LPARAMETER lctabla, lnaccion

lcTabla = UPPER(ALLTRIM( lcTabla ))

*** Global flag to stop writing journal table while recovering data

IF VARTYPE(glstopjournal)=L
IF glstopjournal=.T.
RETURN .T.
ENDIF
ENDIF

LOCAL vcttxsdata(1, 1)
LOCAL lcoldalias, lnOficina

IF EMPTY(lcTabla)
RETURN
ENDIF


IF !USED(lctabla)
RETURN
ENDIF

lcoldalias = ALIAS()

lcTabla = UPPER(ALLTRIM(lcTabla))
SELECT (lctabla)


*** Number of fields on the table
lnnumfields = AFIELDS(vctfields, lctabla)
DIMENSION vcttxsdata(lnnumfields, 2)
FOR i = 1 TO lnnumfields
vcttxsdata(i, 1) = vctfields(i,1)field name
vcttxsdata(i, 2) = EVALUATE(vctfields(i,1))  field value
ENDFOR

IF !USED(Journal)
USE journal ALIAS journal IN 0
ENDIF

lcmachinename = ALLTRIM(MachineName())
lcusername = ALLTRIM(UserName())
*** Writes on the journal
INSERT INTO journal (fechahora, machine, USER, tabla, accion,
pasado) VALUES (DATETIME(), lcmachinename, lcusername, lctabla, lnaccion,
.F.)
*** Writes on the memo field the vector
SELECT journal
SAVE TO MEMO txsdata ALL LIKE vcttxsdata
*** saves modifications
IF CURSORGETPROP(Buffering)=3
TABLEUPDATE(.T.,.T.)
ENDIF

*** HouseKeeping
RELEASE vcttxsdata
RELEASE vctfields
*** Restaura la tabla en que estaba, por si acaso
IF !EMPTY(lcoldalias)
SELECT (lcoldalias)
ENDIF
ENDFUNC

***
*** Recover data from the journal file
***
PROCEDURE RecoverJournal
LPARAMETER lcSyncDataFile
PUBLIC glStopJournal
glStopJournal = .T.
IF !USED(lcSyncDataFile)
USE lcSyncDataFile IN 0 ALIAS SyncDataFile
ENDIF
SELECT SyncDataFile
SCAN
SELECT SyncDataFile
=
mergetx(UPPER(ALLTRIM(SyncDataFile.tabla)),SyncDataFile.accion,SyncDataFile
)
SELECT SyncDataFile
ENDSCAN
RELEASE glStopJournal
ENDPROC
*


**
*** Add, delete and modify data 

**
PROCEDURE MergeTx
LPARAMETER lcTabla, lnAccion, lcAliasJournal
EXTERNAL ARRAY vcttxsdata

LOCAL lnReturnValue
LOCAL vctCampos(1)


IF !USED(lcTabla)
lcAlias = JUSTSTEM(lcTabla)
USE (lcTabla) IN 0 ALIAS lcAlias
ELSE
lcAlias = JUSTSTEM(lcTabla)
ENDIF

AFIELDS( vctCampos, lcalias )

DO CASE
CASE lnAccion=1  INSERT   *** New record
SELECT (lcAliasJournal)
RESTORE FROM MEMO txsdata ADDITIVE
IF VARTYPE(vcttxsdata)=U
RETURN
ENDIF
lnVctLen = ALEN(vcttxsdata, 1)
SELECT (lcAlias)
IF lookforrecord(lcTabla,@vcttxsdata)  0  
Record not found
APPEND BLANK
FOR i = 1 TO lnVctLen
lcFieldName =
UPPER(ALLTRIM(vcttxsdata(i,1)))
IF ASCAN( vctCampos, lcFieldName ) 
0
   

Re: DBF Synchronization

2012-05-07 Thread Paul McNett
On 5/7/12 8:03 AM, Stephen Russell wrote:
 On Mon, May 7, 2012 at 10:01 AM, Kevin Cully
 kcu...@cullytechnologies.com  wrote:
 It'd really help if you used UUIDs (GUIDs) as the primary keys as well.

 -

 I second this statement.

Third.


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa803dd.4030...@ulmcnett.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-07 Thread Rafael Copquin
I have a syncronization table with fields to capture the modified 
table's name, the type of modification (N= new record, D= deleted 
record, M=modified record), a datetime field and a Syncronized field 
(logical)

Every time an update occurs in any table, the operation is recorded in 
the syncronization table. This means that anywhere you update,delete or 
add a new record, in any screen of your system, you should insert a 
record in the sync table.

For instance, you add a new customer to customers.dbf . Therefore you 
add a new record in the sync table, as follows:

replace table with 'customer', type with 'N',dt with datetime(),recnbr 
with (the customer table new pk)

The same if you delete a record or modify one.

Then you go to your office, you select all records from the sync table 
not marked as syncronized and update the server tables as per the 
information you get from that table. So first take all the deleted 
records and delete them in the server, then take all updates and all the 
additions and do the same (update or modify the server table record).

You have to be careful with the relations between parent and child 
tables in respect of the primary and foreign keys, but it depends on how 
you designed your system.

It is a laborious procedure, but it works very well for me.

Rafael Copquin







El 07/05/2012 10:28 a.m., Jeff Johnson escribió:
 Excuse me if this was recently discussed because I thought it was, but
 couldn't find it.  I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization.

 I have looked at DBFSync but it requires selecting each dbf and each
 field to synchronize.  I suppose once you set it up, that would be okay.

 Does anyone use synchronization effectively in their applications?

 TIA


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa8047b.4030...@fibertel.com.ar
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


RE: DBF Synchronization

2012-05-07 Thread José Enrique Llopis

Thanks

Pepe Llopis



-Mensaje original-
De: profox-boun...@leafe.com [mailto:profox-boun...@leafe.com] En nombre de
Eurico Chagas Filho
Enviado el: lunes, 07 de mayo de 2012 19:15
Para: ProFox Email List
Asunto: Re: DBF Synchronization

Nice, thanks for the code.

E.

--- StripMime Report -- processed MIME parts ---
multipart/alternative
  text/plain (text body -- kept)
  text/html
---

[excessive quoting removed by server]

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/8E14E67B91D54023971CDA31B7B3C587@LENOVO1
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-07 Thread AndyD
offline views?

AndyD 8-)₹

On 07/05/2012 14:28, Jeff Johnson wrote:
   I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization

 TIA


___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/4fa8090e.6040...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Re: DBF Synchronization

2012-05-07 Thread MB Software Solutions, LLC
On 5/7/2012 10:54 AM, Stephen Russell wrote:
 On Mon, May 7, 2012 at 8:28 AM, Jeff Johnsonj...@san-dc.com  wrote:
 Excuse me if this was recently discussed because I thought it was, but
 couldn't find it.  I want to synchronize several VFP9 dbf files.  A user
 uses her laptop and then when she returns to the office want's to
 synchronize the dbf's with the server.  A full two way synchronization.

 I have looked at DBFSync but it requires selecting each dbf and each
 field to synchronize.  I suppose once you set it up, that would be okay.

 Does anyone use synchronization effectively in their applications?
 --

 Do you have a datetime column for a row change?  If so you just have
 to update dataB with dataA values when they are not the same.

 If you do not have something like this how are you going to know which
 one is recent?



Good points, but begs the question:  is this a 1-way synch or 2-way?  In 
other words, are changes on the laptop only going to the server, or is 
it possible for server changes to be newer than the laptop and thus you 
go that direction (from server to laptop db)?  If you have the date/time 
stamping like Stephen said, it helps make this possible.

-- 
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa8411e.7090...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.


Re: DBF Synchronization

2012-05-07 Thread MB Software Solutions, LLC
On 5/7/2012 1:40 PM, AndyD wrote:
 offline views?

I saw that in VFP Help years ago but I thought I had heard somewhere 
that they didn't work as well as you might think?


-- 
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16

___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/4fa8a93a.70...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.