I am very interested in EDB 2 but have some questions.  I currently am
finishing up a custom program for a client and using DBISAM 4 converting
data from an old FoxPro application.  I have an EDB 1 license and was
planning to convert the database some day, but had heavily modified the "bde
transfer utility" for this application and didn't want to redo a lot of
work.



However, this particular application will be used by 4 people in 3 remote
offices and they need to synchronize the data on a daily basis.  I was about
to code that last part of this project when I saw the announcement for EDB 2
which included replication!  Now, I want to step up the conversion from
DBISAM to EDB and be ready to roll it out in early April with EDB 2.



My question is about the replication.  There wasn't much information about
it (other than it will use the publish/subscribe method) and I'm not very
familiar with it.  However, I know I will need it and it theoretically will
save me a lot of time!  Is there a web page that talks more about it
specifically?  Will it really be ready by the end of March?  What
configuration options will there be (can I exclude certain tables from being
synchronized)?





Thanks!



David Cornelius

Cornelius Concepts

Custom Software Development

David,

<< My question is about the replication.  There wasn't much information
about it (other than it will use the publish/subscribe method) and I'm not
very familiar with it.  However, I know I will need it and it theoretically
will
save me a lot of time!  Is there a web page that talks more about it
specifically? >>

Not yet.  That information will be available as part of the documentation
with the 2.0 release.

<< Will it really be ready by the end of March? >>

Hopefully.  The hold-up, if there is one, won't be the replication,
however, so I might do a public beta so people can start playing.

<< What configuration options will there be (can I exclude certain tables
from being synchronized)? >>

Here are the applicable SQL statements:

Publishing
----------

PUBLISH DATABASE <DatabaseName>
[TABLES <TableName> [,<TableName>]]
[TO SUBSCRIBER|PUBLISHER|BOTH]

UNPUBLISH DATABASE <DatabaseName>
[TABLES <TableName> [,<TableName>]]

Subscribing
-----------

CREATE PUBLISHER <Name>
HOST <HostName>|ADDRESS <IPAddress>
SERVICE <ServiceName>|PORT <PortNumber>
[ENCRYPTED WITH PASSWORD <EncryptionPassword>]
[COMPRESSION <Compression>]
[TIMEOUT <Timeout>]
USER <UserName>
PASSWORD <Password>
[DESCRIPTION <Description>]

ALTER PUBLISHER <Name>
HOST <HostName>|ADDRESS <IPAddress>
SERVICE <ServiceName>|PORT <PortNumber>
[ENCRYPTED WITH PASSWORD <EncryptionPassword>]
[COMPRESSION <Compression>]
[TIMEOUT <Timeout>]
USER <UserName>
PASSWORD <Password>
[DESCRIPTION <Description>]

DROP PUBLISHER <Name>

CREATE SUBSCRIBER <Name>
[DESCRIPTION <Description>]

ALTER SUBSCRIBER <Name>
[DESCRIPTION <Description>]

DROP SUBSCRIBER <Name>

CREATE SUBSCRIPTION <Name>
TO PUBLISHER <PublisherName>
AS <SubscriberName>
SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
[DESCRIPTION <Description>]

ALTER SUBSCRIPTION <Name>
TO PUBLISHER <PublisherName>
AS <SubscriberName>
SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
[DESCRIPTION <Description>]

DROP SUBSCRIPTION <Name>

Synchronizing
-----------

SYNCHRONIZE <SubscriptionName>

These are not written in stone, however.  One thing that might get added,
for example, is a filter criteria for each table so that only a subset of
each table is looked at in terms of the synchronization.   This is useful
for only having each remote office grab their data that pertains to their
office, for example.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the reply.  I'm very interested in helping beta-test this as soon
as it's ready.  My client is chomping at the bit to start using their new
software.  By the end of this month, synchronization between the remote
offices, will be the last piece to put in place (not that I want to add any
pressure to your schedule or anything!).

Thanks also for listing the SQL.  I'll study other replication references
and try to be well versed so when this is available, I'll be able to hit the
ground running.

Looking forward to it!  I'll call in my 2.0 pre-order!


David Cornelius
http://CorneliusConcepts.com
custom software development


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A334F862-5539-4588-A14F-A3B6EC85995B@news.elevatesoft.com...
> David,
>
> << My question is about the replication.  There wasn't much information
> about it (other than it will use the publish/subscribe method) and I'm not
> very familiar with it.  However, I know I will need it and it
> theoretically will
> save me a lot of time!  Is there a web page that talks more about it
> specifically? >>
>
> Not yet.  That information will be available as part of the documentation
> with the 2.0 release.
>
> << Will it really be ready by the end of March? >>
>
> Hopefully.  The hold-up, if there is one, won't be the replication,
> however, so I might do a public beta so people can start playing.
>
> << What configuration options will there be (can I exclude certain tables
> from being synchronized)? >>
>
> Here are the applicable SQL statements:
>
> Publishing
> ----------
>
> PUBLISH DATABASE <DatabaseName>
> [TABLES <TableName> [,<TableName>]]
> [TO SUBSCRIBER|PUBLISHER|BOTH]
>
> UNPUBLISH DATABASE <DatabaseName>
> [TABLES <TableName> [,<TableName>]]
>
> Subscribing
> -----------
>
> CREATE PUBLISHER <Name>
> HOST <HostName>|ADDRESS <IPAddress>
> SERVICE <ServiceName>|PORT <PortNumber>
> [ENCRYPTED WITH PASSWORD <EncryptionPassword>]
> [COMPRESSION <Compression>]
> [TIMEOUT <Timeout>]
> USER <UserName>
> PASSWORD <Password>
> [DESCRIPTION <Description>]
>
> ALTER PUBLISHER <Name>
> HOST <HostName>|ADDRESS <IPAddress>
> SERVICE <ServiceName>|PORT <PortNumber>
> [ENCRYPTED WITH PASSWORD <EncryptionPassword>]
> [COMPRESSION <Compression>]
> [TIMEOUT <Timeout>]
> USER <UserName>
> PASSWORD <Password>
> [DESCRIPTION <Description>]
>
> DROP PUBLISHER <Name>
>
> CREATE SUBSCRIBER <Name>
> [DESCRIPTION <Description>]
>
> ALTER SUBSCRIBER <Name>
> [DESCRIPTION <Description>]
>
> DROP SUBSCRIBER <Name>
>
> CREATE SUBSCRIPTION <Name>
> TO PUBLISHER <PublisherName>
> AS <SubscriberName>
> SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
> TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
> [DESCRIPTION <Description>]
>
> ALTER SUBSCRIPTION <Name>
> TO PUBLISHER <PublisherName>
> AS <SubscriberName>
> SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
> TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
> [DESCRIPTION <Description>]
>
> DROP SUBSCRIPTION <Name>
>
> Synchronizing
> -----------
>
> SYNCHRONIZE <SubscriptionName>
>
> These are not written in stone, however.  One thing that might get added,
> for example, is a filter criteria for each table so that only a subset of
> each table is looked at in terms of the synchronization.   This is useful
> for only having each remote office grab their data that pertains to their
> office, for example.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Tim


As far as I can see from your posts replication will be a purely c/s phenomenon which is a shame. I can see a great use for it in file server holding some tables (eg validation/lookup) local but keeping them up to date as well.

I'm guessing the chances of it happening are zero?

Roy Lambert

David,

<< Thanks for the reply.  I'm very interested in helping beta-test this as
soon as it's ready.  My client is chomping at the bit to start using their
new software.  By the end of this month, synchronization between the remote
offices, will be the last piece to put in place (not that I want to add any
pressure to your schedule or anything!). >>

Well, it should be the first major item ready to go, so I have no problem
allowing people to play with it earlier than the actual release.

<< Looking forward to it!  I'll call in my 2.0 pre-order! >>

Thanks very much.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< As far as I can see from your posts replication will be a purely c/s
phenomenon which is a shame. >>

It will require an ElevateDB Server on the publishing end, yes.  Otherwise
there's really no way to perform the synchronization.  On the subscriber
end, however, you can use single-user, multi-user, or C/S with no problems.

In other words, you could have a bunch of hand-held devices using .NET CF
(once WinCE support is done) synchronizing to a local office, which then
synchronizes to a main office.  The hand-held devices could be simple
single-user applications that don't require the ElevateDB Server at all.

--
Tim Young
Elevate Software
www.elevatesoft.com

Each user has a complete local copy of the database and will be synchronizing with a
remote C/S database.  The reason everyone has a local database is because almost everyone
is in a remote office and may experience internet disruptions or may be on the road with a
laptop.  They like the speed of instantly accessing anything they need.

So yes, replication will be a savior in this project for me as that was a tricky part I
was saving for last.  But now it will be a simple replication subscription from each
workstation to a server.

BTW, I'm excited about the future prospects of a CF version!

--
David Cornelius
Cornelius Concepts
Custom Software Development


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Roy,

<< As far as I can see from your posts replication will be a purely c/s
phenomenon which is a shame. >>

It will require an ElevateDB Server on the publishing end, yes.  Otherwise
there's really no way to perform the synchronization.  On the subscriber
end, however, you can use single-user, multi-user, or C/S with no problems.

In other words, you could have a bunch of hand-held devices using .NET CF
(once WinCE support is done) synchronizing to a local office, which then
synchronizes to a main office.  The hand-held devices could be simple
single-user applications that don't require the ElevateDB Server at all.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

<< Each user has a complete local copy of the database and will be
synchronizing with a remote C/S database.  The reason everyone has a local
database is because almost everyone is in a remote office and may experience
internet disruptions or may be on the road with a laptop.  They like the
speed of instantly accessing anything they need.

So yes, replication will be a savior in this project for me as that was a
tricky part I was saving for last.  But now it will be a simple replication
subscription from each workstation to a server. >>

Yes, it will work quite well for you.

<< BTW, I'm excited about the future prospects of a CF version! >>

Yeah, it should be pretty cool.

--
Tim Young
Elevate Software
www.elevatesoft.com

Just wondering how you prevent record conflicts using your replication.  What if the
primary key is an autoinc and records with the same autoinc values are added at different
locations.  For example add employee "John", PK = 1 at location 1, add employee "Brad", PK
= 1 at location 2.

The way I've done this in the past is have a primary key that is a combination of
LocationID (word) + sequential number (longint).  That way I was ensured to never have a
record conflict or PK conflict.

Thanks,
Rob


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

David,

<< My question is about the replication.  There wasn't much information
about it (other than it will use the publish/subscribe method) and I'm not
very familiar with it.  However, I know I will need it and it theoretically
will
save me a lot of time!  Is there a web page that talks more about it
specifically? >>

Not yet.  That information will be available as part of the documentation
with the 2.0 release.

<< Will it really be ready by the end of March? >>

Hopefully.  The hold-up, if there is one, won't be the replication,
however, so I might do a public beta so people can start playing.

<< What configuration options will there be (can I exclude certain tables
from being synchronized)? >>

Here are the applicable SQL statements:

Publishing
----------

PUBLISH DATABASE <DatabaseName>
[TABLES <TableName> [,<TableName>]]
[TO SUBSCRIBER|PUBLISHER|BOTH]

UNPUBLISH DATABASE <DatabaseName>
[TABLES <TableName> [,<TableName>]]

Subscribing
-----------

CREATE PUBLISHER <Name>
HOST <HostName>|ADDRESS <IPAddress>
SERVICE <ServiceName>|PORT <PortNumber>
[ENCRYPTED WITH PASSWORD <EncryptionPassword>]
[COMPRESSION <Compression>]
[TIMEOUT <Timeout>]
USER <UserName>
PASSWORD <Password>
[DESCRIPTION <Description>]

ALTER PUBLISHER <Name>
HOST <HostName>|ADDRESS <IPAddress>
SERVICE <ServiceName>|PORT <PortNumber>
[ENCRYPTED WITH PASSWORD <EncryptionPassword>]
[COMPRESSION <Compression>]
[TIMEOUT <Timeout>]
USER <UserName>
PASSWORD <Password>
[DESCRIPTION <Description>]

DROP PUBLISHER <Name>

CREATE SUBSCRIBER <Name>
[DESCRIPTION <Description>]

ALTER SUBSCRIBER <Name>
[DESCRIPTION <Description>]

DROP SUBSCRIBER <Name>

CREATE SUBSCRIPTION <Name>
TO PUBLISHER <PublisherName>
AS <SubscriberName>
SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
[DESCRIPTION <Description>]

ALTER SUBSCRIPTION <Name>
TO PUBLISHER <PublisherName>
AS <SubscriberName>
SOURCE DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
TARGET DATABASE <DatabaseName> [TABLES <TableName> [,<TableName>]]
[DESCRIPTION <Description>]

DROP SUBSCRIPTION <Name>

Synchronizing
-----------

SYNCHRONIZE <SubscriptionName>

These are not written in stone, however.  One thing that might get added,
for example, is a filter criteria for each table so that only a subset of
each table is looked at in terms of the synchronization.   This is useful
for only having each remote office grab their data that pertains to their
office, for example.

--
Tim Young
Elevate Software
www.elevatesoft.com

Rob,

<< Just wondering how you prevent record conflicts using your replication.
>>

Currently we are punting on the IDENTITY column issue, at least as far as
EDB providing any automatic solution.  Therefore, you'll have to include a
location identifier yourself if you wish to prevent conflicts of this
nature.

As far as conflicts in general are concerned, you will be allowed to define
a conflict handler that is like a trigger for dealing with conflicts and
taking the appropriate course of action.

--
Tim Young
Elevate Software
www.elevatesoft.com