Hi!
You can define the selection query for each replication procedure, and that query, say, will get some parameters that are application-wide (such as user name, user privilegies etc.). This query will be able to select data required for replication. For example:
* query to select all public customers or private customers for that user
SELECT * from Customers where lPublic OR cUserName==oApp.UserName
* query to select all items for public customers or private customers for that user
SELECT I.* from Items I inner join Costomers C on I.CustID=C.CustID ;
where C.lPublic OR C.cUserName==oApp.UserName
This way you can organize filtering. I guess filtering will not be dynamic (user cannot change it, it is just a part of the business logic in replication), so you can store such query for filtering in the table defining replication rules. No need to catch every relation and do complex algorithm for data pick up - you do not try to make something like a generic replication service, right? ;) Keep it simlpe where time to implement something is too big.
>Hi,
> Thank you for your advise. I am starting to develop the module of replication. However, I face some problems here.
>
>My design:
>1. I store all tablenames in a table named tbltables. It has a field that specific the "role" of the particular table in replication. It is either send to server, send to client or both.
>
>2. Then, it also has some memo fields that will store the coding of each tables to execute some extra process before/after the replication done. For example, a after replication process for sales that will update member's points base on each member sales.
>
>3. My program will SCAN thorugh those tables recorded in tbltables and verify it's role. Then, compare each records with it's backup table (which will be copy to another folder after replication). Any new/updated records will be insert to another table in a folder called ForwardFolder.
>
>Hmm.. I think the design above should be fine.. (still under design and testing)... however, if I need to have filtering of the records before replication, how should I design it, expecially there are some master and child relatinship tables. For example, sales will have a child table called sdetails.
>
>So, only records that belong to master sales table (which is valid for replication) should be copied. How to do this?
>
>Do you think I should record the master table of each table (if any) in tbltables, then re-execute master table's filtering procedure again in order to get child records??
>
>Do you have any suggestion?
>
>Thank you in advance.
>Please don't hestitate to ask if any unclear matter.
Vlad Grynchyshyn, Project Manager, MCP
vgryn@yahoo.comICQ #10709245
The professional level of programmer could be determined by level of stupidity of his/her bugs
It is not appropriate to say that question is "foolish". There could be only foolish answers. Everybody passed period of time when knows nothing about something.