We have a warehouse and manufacturing software system that was originally
written in Clipper (using DBFCDXAX) and then converted to GUI and Xbase++
using ADSDBE.
We now have a situation with our biggest customer who has not yet upgraded
to the Windows version because he has been investigating other software for
the past 3 years. He keeps coming back to us because he has come to realize
that migrating his entire multi-state enterprise to a new system is
unpratical, however he wants an application that uses an industrial strength
database. He seems to be hooked on MSSQL simply because it's Microsoft, not
for any other reason. We have convinced him that ADT is just as tough as
any SQL database and can be queried and managed like any SQL database while
still giving us the advantages of record-based systems. We also convinced
him that he can use Crystal Reports.
Now we are trying to deal with the concurrency issues. We have no problem
running the old Clipper app and the new Xbase++ app concurrently, however
when and if we move to ADT this becomes a big problem. They have hundreds
and hundreds of workstations and we simply cannot flip a switch over to the
new system. We need to gradually move groups of workers to the new system
through a phase-out plan that could take over a year.
Can the Advantage Replication system be used to resolve this issue for us?
Hi Roger,
It is possible to set up replication rules that will replicate from ADT to
DBF and vice versa. As long as the table structures are compatible, it
should work fine. However, the replication is asynchronous and the latency
can vary depending on how busy the system is. This means that if someone
updates a record in the DBF table at the "same time" someone else updates
the equivalent record in the ADT table, then there could be conflicts. If
you just use the primary key to identify the record, then the last update
will win. If this is not acceptable, then you would need to define conflict
triggers to handle these situations.
There is, however, another difficulty with replication and Clipper
applications. Replication requires data dictionaries. It is not possible
to connect to a data dictionary with a Clipper application. This means that
if you start the clipper application and update a table, the change will not
be replicated ... unless the table has already been opened "in" the data
dictionary (e.g., within Advantage Data Architect). In other words, it
would be necessary to always be sure to open all of the DBF tables first
through something that connects to the data dictionary before updating them
with a Clipper application. This seems like it could be problematic.
Mark Wilkins
Advantage R&D
This is understandable. We thought about this. My inclination, at this
time,
is to not move to ADT until the the Clipper app is fully retired.
> There is, however, another difficulty with replication and Clipper
> applications. Replication requires data dictionaries. It is not possible
> to connect to a data dictionary with a Clipper application. This means
> that if you start the clipper application and update a table, the change
> will not be replicated ... unless the table has already been opened "in"
> the data dictionary (e.g., within Advantage Data Architect). In other
> words, it would be necessary to always be sure to open all of the DBF
> tables first through something that connects to the data dictionary before
> updating them with a Clipper application. This seems like it could be
> problematic.
This is NOT a problem. We would run an Xbase++ application that always
connects to the DD. Thanks for your ideas.
different idea: Add a data dictionary to your database, add all DBF
tables to it. Then convert your Xbase++ Application to connect to the
data dictionary, but keep the DBF files as long as the clipper app
lives.
If the Clipper app dies, switch to ADT...there's no need to change the
application, since it already uses the dictionary and the table type is
ignored in that case.
Please bear in mind that switching from DBF to ADT has differences in
Inex handling and NULL (Empty) fields.
--
Joachim Duerr
Senior Product Support Analyst (Advantage Database Server)
iAnywhere Solutions / Extended Systems
advantage[AT]extendsys.de
I read this in one of your earlier postings. This is a good idea.
Thanks.