Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 15 total |
EDB 2.0: Replication |
Mon, Mar 10 2008 1:29 AM | Permanent Link |
"David Cornelius" | 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 |
Mon, Mar 10 2008 4:10 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Mar 11 2008 2:42 AM | Permanent Link |
"David Cornelius" | 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 > |
Tue, Mar 11 2008 3:52 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Mar 11 2008 4:45 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Mar 11 2008 4:48 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, Mar 14 2008 6:12 PM | Permanent Link |
David Cornelius | 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 |
Tue, Mar 18 2008 3:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Mon, Apr 21 2008 8:15 PM | Permanent Link |
Rob Fletcher | 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 |
Tue, Apr 22 2008 5:52 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, July 4, 2024 at 07:01 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |