Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 43 total |
Bi-Directional Replication. |
Tue, Aug 16 2016 10:49 PM | Permanent Link |
Steve Gill | I'm developing a system that allows multiple offices to exchange their data. As replication happens at the database level I'm assuming I will have to come up with a way to synchronise things like users and passwords?
= Steve |
Wed, Aug 17 2016 4:04 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Steve
>I'm developing a system that allows multiple offices to exchange their data. As replication happens at the database level I'm assuming I will have to come up with a way to synchronise things like users and passwords? That depends (I do like starting an answer like that) Will all the people need to be able to log in to the system at every workstation? Is access to the data dependent on who's logged in? If its simply a matter of some of the columns are the user ID but its simply for information then it doesn't matter. As an example - in my recruitment app which I use every day we track calls made to people, emails sent etc. Part of that is the user ID (mine is RL strangely enough) so that anyone using the system can see if there's been a contact with an individual and if so who made it. If the system was operating on a replicated database the only reason for synchronising users and passwords would be so the system doesn't allow another RL. In my case there's a staff table which holds a lot more information than just the user ID (it doesn't hold the password that's only in ElevateDB) so I can do what I need. A bit rambly but I hope it helps. RL aka Roy Lambert |
Wed, Aug 17 2016 4:29 AM | Permanent Link |
Adam Brett Orixa Systems | Steve
>>I'm assuming I will have to come up with a way >>to synchronise things like users and passwords? Only if users from Office "A" (where they are set up as Users) regularly travel to Office "B". My own systems of replication tend to consist of a central server in the office, with individual laptops as the nodes (the "salesman model"), users with laptops always use their laptop even if they are in the office, so provided they can log into their own device everything is easy. Replication has been quite cleverly defined in EDB in quite a clean but open way, which allows quite a wide range of implementations (1 central node, several central nodes with data-exchange, chaining of updates, use of replication as a form of Backup process ...). This does also mean that you are in charge, and it won't automatically do exactly what you want. I put a simple-but-working Replication test programme on the binaries forum a year ago, which you might like to play with (http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_binaries&msg=81&page=1). One of the biggest gotchas is what happens when your DB structure changes. Bear in mind replication only works between tables with the same structures, so structure changes must be done carefully to avoid losing integrity between nodes in a replicating system. Once you get it working it is magic. |
Wed, Aug 17 2016 5:33 PM | Permanent Link |
Steve Gill | Roy and Adam,
Yes, users may move between offices and expect to be able to access their personal data in any office they visit. I'll have to work out a way to exchange information on new users, deleted users, renamed users, password changes, etc. << In my case there's a staff table which holds a lot more information than just the user ID (it doesn't hold the password that's only in ElevateDB) so I can do what I need. >> Yeah, I do something similar with a UserData table. << One of the biggest gotchas is what happens when your DB structure changes. Bear in mind replication only works between tables with the same structures, so structure changes must be done carefully to avoid losing integrity between nodes in a replicating system. >> Ahh, good point. I'll have to work out a solution to make sure they all use the same database structure. = Steve |
Thu, Aug 18 2016 3:21 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Steve
Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler. Roy Lambert |
Thu, Aug 18 2016 3:44 AM | Permanent Link |
Steve Gill | Hi Roy,
<< Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler. >> They're held n the configuration.users table so yes it's a bit more awkward. = Steve |
Thu, Aug 18 2016 11:32 PM | Permanent Link |
Jeff Cook Aspect Systems Ltd | On 18/08/2016 7:44 PM, Steve Gill wrote:
> Hi Roy, > > << Where are the user passwords held - if its in the config (I think its at that level not the catalog) then it will be more awkward. If they're held in UserData then its simpler. >> > > They're held n the configuration.users table so yes it's a bit more awkward. > > = Steve > Hi Steve It isn't too hard to accomplish (if I understand your requirements). This is how I have done it:- 1. Designate one server to be "chief" and the rest are "slaves". 2. On "chief" run a JOB that creates an export file containing all the users, passwords and any other custom stuff you require. I exclude some special admin users from the file. My JOB runs every 15 minutes. 3. On "Chief" have JOB for each "slave" that pushes the file to each of the "slaves". Also runs every 15 minutes. 4. Write a simple program that runs on the "slave" which picks up the export file and uses it to add/change/delete users on the "slave". This program runs from the Startup menu and uses a timer, also every 15 minutes. HTH Cheers Jeff |
Fri, Aug 19 2016 2:59 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jeff
I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear. Roy Lambert |
Fri, Aug 19 2016 10:12 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear. >> If you're using the EDB Server, then users shouldn't have *any* access to any of the drives/directories that the server uses for databases, stores, etc. So, as long as the transport layer uses encryption to transfer the files (like an encrypted connection between EDB Servers with remote stores), then you'll be okay. Just make sure to delete/overwrite such files periodically (master), or after they are transferred (slave). Tim Young Elevate Software www.elevatesoft.com |
Fri, Aug 19 2016 10:55 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< I was loath to suggest anything like that because I don't know a way to export a table in an encrypted fashion so the passwords are there in the clear. >> > >If you're using the EDB Server, then users shouldn't have *any* access to any of the drives/directories that the server uses for databases, stores, etc. So, as long as the transport layer uses encryption to transfer the files (like an encrypted connection between EDB Servers with remote stores), then you'll be okay. Just make sure to delete/overwrite such files periodically (master), or after they are transferred (slave). My view on that would depend on the nature of the application and any security implications. At the "die before reading" end of the scale having the passwords sitting in the clear on a hard drive for even a brief period of time isn't a good idea. At the "who cares" end of the scale - well who cares Roy |
Page 1 of 5 | Next Page » | |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |