Server - Client Side

[skoko]

Situation is like this.

Users use local application and local server database. So, we have five same databases (on five servers).

Standalone application is on 6th server with timer on 1 second for checking local table for new updates. When user make changes, application save that and send to server (stand-alone) which record is changed (timestamp, table, server path and record number). Server Replicate this record to other servers. Work perfectly. Client side is in real time. Server side takes 2 seconds to replicate record to other servers.

Bad thing is adding record becuase I'm using recno() to locate record.

Let say, user X add new record at XX:XX:XX and send this information to server. Record number is 17736.
Next second, another user add new record, but, again, new record is still 17736. Now, we have situation: same record number, different records.

I hope that somebody understand me ))))

 

[skoko]

So, that means that I still need to use SEEK to search for nRecno. Correct?

 

[chpicker]

Not necessarily. You receive a record that has a field called "nRecno". You use that value in your GOTO statement.

Without knowing how your servers work, this is all pure speculation. I don't know how you do your data synchronization. Without that, it's very hard to suggest how to change your system for this to work.

Ian

 

[skoko]

Ok, but I still dont understand:

Server 1 append new record: 17736
Server 2 append new record: 17736
Both send this information to Master Server.
Master Server change nRecno (field) on Server 2 to 17737.

But, still recno of new record on Server 2 is 17736, only field nRecno is correct.

Server 3 make changes on record 17736 and send this information (17736) to Master Server.
Master Server try to replicate that to other 4 servers, but, 17736 on Server 2 is not this record.

Do u understand me?

 

[DEDMOD]

Here's what I'd do. At each local server produce a preliminary record number where the preliminary record number is like '040017736' telling the local server that this isn't a permanent record number and so don't do anything with it. When the master server gets the record it will know that on server 4 the current record is 17736 and so that's the one to overwrite with the final record number. This would also be an easy way for the master server to tell what new records are there by selecting those over a million or 10 million or whatever. Dave Dardinger

 

[skoko]

Dedmod, good idea, i'm gonna think about that.
At this momment, application open all databases and all tables from all 5 servers at startup. That takes about 2 minutes and after that use seek in almost real time for replication.

This is not bed solution because server side application will runing all the time with exception of packing on weekly basis. Two minutes to wait weekly is not that bad.

Work perfect, I'm very excited ))))

 

[wgcs]

Nice and sweet.

I think the key is that when data is added by the clients on the "Local" servers, the data CANNOT go directly into the local servers' table (maybe into a temp table, "Additions&quot. On the timer, The new records then get sent to the Main server and are deleted from the "Additions" table.

On a second timer (or as the second task on the same timer), The "Local" server gets the updates from the Main server, and with it, it get's back the same record it just sent, only this time with the proper RecNo.

Since the only thing being added to the Real local table is what comes from the server, it's recNo can be kept to match the one on the server (or it can store the RecNo() from the server in a field locally and update the one on the server with that RecNo(), regardless of the local RecNo() )

 

[skoko]

I was thinking about temp tables myself, but in that case we have one way communication more.

Like I say, at this momment I'm very satisfied, in future, idea is winsock. I play with that for a couple days and wooow, results can be very fast.


Guys, thank u all.