I am not a big fan of wildcards like this. First of all, it takes a
bit longer, second of all, you lose a LOT of control. Imagine a case
where you want to extract data from one Btrieve file into another
(separate, non-replicated) file -- the wildcard will add it to your
replication environment. Or, another example would be an application
creating a temp table in the data directory -- which is now added to
replication, and when the file is deleted, the replication breaks.
You should be aware that while files can be easily added with this
method, removing files from replication this easily it NOT possible,
and it requires downtime to remove the tables. Avoiding wildcards is an
easy way to prevent shooting yourself in the foot.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@[EMAIL PROTECTED]
Chicago: Pervasive Service & Sup****t Class - 11/13/2007 ***
Karl A. Sxrensen wrote:
> Using "DIR ..\*.BTR" works. I had just not waited long enough. When
> this filter was on, the first replication took far more time, than
> when just including the new table.
>
> Regards
> Karl
>
> "Karl A. Sxrensen" <kas@[EMAIL PROTECTED]
> wrote in message
> news:472064d9$0$3496$8404b019@[EMAIL PROTECTED]
> > Thanks Bill:)
> > This makes it far easier to upgrade the database.
> >
> > If I add "DIR ..\*.btr" with DXDynPath, it don't seem to work, but
> > if I use "DIR ..\NewTableName.BTR" it works. I was hoping that I
> > could just have the "DIR ..\*.BTR" filter set (at all times). Then
> > any new table would be automatically added. From what I read in
> > the do***entation, this should work, but it does'nt seem to work
> > for me. Anyway, adding each new table is not too much work, when
> > all I have to do is add it with DXDynPath.
> >
> > If anyone needs to know what I did, here is the steps I did.
> > My database folder is "e:\PSQLDatabaser\TOM". DSN=TOM
> > My "shadow" (replicating database) is in folder
> > "e:\PSQLDatabaser\Tom\DX_TOM". DSN=TOMReplica
> >
> > 1. Make sure nobody is using the database.
> > 2. Add table "NewTable.btr" to the databse (DSN=TOM).
> > 3. Run this command line 'DXDynPath /t=include /pa="DIR
> > ..\NewTable.btr" replace TOMReplica'. 4. Do a minor change in the
> > "NewTable.btr" (e.g. add a record). 5. Manually start a
> > replication. I can now see that "NewTable.btr" appears at the
> > partner site. 6. Run this command line to remove the filter set in
> > point 3. 'DXDynPath /t=include /pa="" replace TOMReplica'
> >
> > P.s. If you already use filters to add dynamically created tables,
> > you will delete them if you follow my (Bill's) receipe. But if you
> > have set up filters before, then you would know this.
> >
> > Regards
> > Karl
> >
> >
> >"Bill Bach" <goldstar@[EMAIL PROTECTED]
> wrote in message
> news:SNidnYJdt-L6EoLanZ2dnUVZ_sTinZ2d@[EMAIL PROTECTED]
> > > There is an easy solution -- use the DXDYNPATH tool to specify
> > > the new table to the database, then go and open it and make a
> > > simple change. The next replication cycle will create the table
> > > at the secondary site, and the replication window following will
> > > push the data across.
> > >
> > > Once the file is part of your replication list, you can remove it
> > > from DXDYNPATH.
> > > Goldstar Software Inc.
> > > Pervasive-based Products, Training & Services
> > > Bill Bach
> > > BillBach@[EMAIL PROTECTED]
> > > http://www.goldstarsoftware.com
> > > *** Chicago: Pervasive Service & Sup****t Class - 11/13/2007 ***
> > >
> > >
> > > Karl A. Sxrensen wrote:
> > >
> > > > We are in the process of deploying DataExchange 2.8 at a
> > > > customer site, but I can't figure out a simple routine to add a
> > > > table to a
> >>>replicated database. This is a one way backup (first site -->
> partner
> > > > site), where the database at the partner should function as a
> > > > backup, in case of hardware failures and so on.
> > > >
> > > > How to modify a table:
> > > > 1. Stop replication service at the partner site.
> > > > 2. Upgrade the database at first and partner site.
> > > > 3. Start replication service at the partner site.
> > > > This works.
> > > >
> > > > I then try to add a new table to the database like this:
> > > > 1. Stop replication service at the partner site.
> > > > 2. Add new table, both at first, and partner site.
> > > > 3. Start replication service at the partner site.
> > > >
> > > > This does not work. When I add records to the new table at the
> > > > first site, they don't appear in the database at the partner
> > > > site. I'm quite sure that the reason for this, is that the
> > > > replication engine don't know about this new table. My problem
> > > > is that I don't know how to make the replication engine aware
> > > > of this new table to replicate.
> > > >
> >>>This database is quite large. It contains > 700 tables, and is
> around
> > > > 100GB, so running the DX Deployment tool again (for the whole
> > > > database) is not an option. There has to be an easy way of
> > > > adding this new table to the replication engine.
> > > >
> > > > TIA
> > > > Karl
> > >
> > >
> > >
> > > --
> >
> >
--
|
