Hi all,

I've started looking at RemObjects as a possible way to make client's DBISAM databases available outside of their networks, especially in cases where clients have multiple offices or where some staff work from home.  Has anyone here used RemObjects with DBISAM to do something similar?

Thanks,

Steve

Oops, sorry, wrong forum.  Although this question equally applies to ElevateDB so if someone has done this with RemObjects and ElevateDB I'd be interested.

Thanks,

Steve

Sorry Steve, I don't work with RemObjects, but I do use EDB's replication features extensively to enable remote working. While it is not simple it does work and allows users to maintain a local copy of the db on their laptops, then update it periodically via connection to either a cloud or central network machine.

... its not such a big leap from DBISAM ... and there are lots of other great features.

<< Sorry Steve, I don't work with RemObjects, but I do use EDB's replication features extensively to enable remote working. While it is not simple it does work and allows users to maintain a local copy of the db on their laptops, then update it periodically via connection to either a cloud or central network machine.

... its not such a big leap from DBISAM ... and there are lots of other great features. >>

Thanks Adam, I have ElevateDB (and EWB) as well as DBISAM but haven't used it yet for this particular product.  I'm not sure how practical replication would be in this situation as the data needs to be up to date, to the minute.  In other words, if I update some information, remote users need to have that information almost immediately.

>>Thanks Adam, I have ElevateDB (and EWB) as well as DBISAM but haven't used it yet for this particular product.  >>I'm not sure how practical replication would be in this situation as the data needs to be up to date, to the minute.  >>In other words, if I update some information, remote users need to have that information almost immediately.

Ouch, that sounds tough, remote users are by definition remote ... so there are bound to be difficulties maintaining really up-to-the-minute data.

I do updates hourly or every 20 min on my systems. With that it is still possible for data to lag by twice the "rate of update" (a user can add a record at 1pm and not have their personal update process run until 1.59, then another user might not have _their_ update process run until 2.59 to "receive" the update).

EDB Is still pretty clever by itself, even without something like REM ... for instance you can set UPDATE files to only be created if there is new data, then you could set a trigger to only run when an update was present ... but check for the existence of the file regularly (every few seconds). That would give regular semi-live updates, but only when live changes were actually happening.

<< EDB Is still pretty clever by itself, even without something like REM ... for instance you can set UPDATE files to only be created if there is new data, then you could set a trigger to only run when an update was present ... but check for the existence of the file regularly (every few seconds). That would give regular semi-live updates, but only when live changes were actually happening. >>

Thanks Adam, that sounds like a good solution.

-Steve

Adam,

<< EDB Is still pretty clever by itself, even without something like REM ...
for instance you can set UPDATE files to only be created if there is new
data, then you could set a trigger to only run when an update was present
.... but check for the existence of the file regularly (every few seconds).
That would give regular semi-live updates, but only when live changes were
actually happening. >>

^^^ This.

A scheduled job can be run every minute, so you can have the job looking for
update files in the outbound store and, when present, copying them from one
that store to the other remote location's inbound store using COPY FILE.
Then, have the same scheduled job looking for incoming update files in its
inbound store, and then loading them as appropriate.  Have the other side
doing the same, and you're all set.  Because the update files are
compressed, by default, you won't end up transferring very much data at a
time.

The example outlined here is a good starting point with the replication:

http://www.elevatesoft.com/articles?action=view&category=edb&article=building_sales_quote_replication_system_elevatedb

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

<< ^^^ This.

A scheduled job can be run every minute, so you can have the job looking for
update files in the outbound store and, when present, copying them from one
that store to the other remote location's inbound store using COPY FILE.
Then, have the same scheduled job looking for incoming update files in its
inbound store, and then loading them as appropriate.  Have the other side
doing the same, and you're all set.  Because the update files are
compressed, by default, you won't end up transferring very much data at a
time.

The example outlined here is a good starting point with the replication:

http://www.elevatesoft.com/articles?action=view&category=edb&article=building_sales_quote_replication_system_elevatedb >>

Thanks Tim, sounds perfect.

<< The example outlined here is a good starting point with the replication:

http://www.elevatesoft.com/articles?action=view&category=edb&article=building_sales_quote_replication_system_elevatedb >>

Hi Tim,

That seems like an excellent solution, except for one thing.  The customer will need to open ports on their router, set up port forwarding, and have a static IP address or use one of the dynamic IP address services.   
Unfortunately this is beyond the abilities of most of my customers, and I don't really want to remote in and set it up for them.  

I suppose I need to come up with a method of exchanging the update files between the EDB servers without using remote stores.  Hmm, that gives me something to work on.

-Steve

Steve,

<< I suppose I need to come up with a method of exchanging the update files
between the EDB servers without using remote stores.  Hmm, that gives me
something to work on. >>

Email, FTP, and/or HTTP will work fine also.  As soon as you pop the update
files into the correct inbound store directory, the process works the same.

Tim Young
Elevate Software
www.elevatesoft.com