Database Realtime

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Database Realtime by atcroft (Abbot) on Jul 03, 2004 at 03:38 UTC
I would think one way you might could go about this would be to use autocommit of the transactions (inserts/updates/deletes/replacements), and an interface that either was user-driven for pulling updates (hit a button to check for updates) or timed to look for updates (such as a meta-refresh if the interface is via a webpage to pull the updates). Hope that helps....	[reply]
Re^2: Database Realtime by Anonymous Monk on Jul 03, 2004 at 04:12 UTC
Yes. I think either one of these would be the best approach. I was jus thinking that applying changes without the user seeing the affect could be problematic in the long run with multiple users on the system. NG	[reply]
Re: Database Realtime by beable (Friar) on Jul 03, 2004 at 03:23 UTC
What kind of database is it? When somebody adds or removes an object, you commit the change right? Then if people need to see the changes, they could click on a "Refresh" or "Get updated view" button, which selects the current table.	[reply]
Re: Database Realtime by Anonymous Monk on Jul 03, 2004 at 04:09 UTC
I will be using Access for the database. One option I was looking at was to send the user a message stating that there were changes to the the database. Should the user wish to proceed with the changes it would then refresh the screen for them. One other other options that I will be looking at is to wrap this whole project around a Tk interface so they would have no need to go to the website in order to do the modifications to the database. I guess where I am lost is I know I can get the user to the database and I can hold changes in a temp section and check to see if anyone else is in that table, etc. If they are not apply the changes to the table, etc. But what i would like to do is show the changes dynamically to everyone at onetime. Would it be more of a forced push on everyone? Or do you think that would be a good idea at all? Or would it be better to let the user have a choice and then when they go to publish their changes show them the current changes and then show them what their changes will effect? NG	[reply]
Re^2: Database Realtime by bart (Canon) on Jul 03, 2004 at 10:17 UTC
I will be using Access for the database. Ouch. One word of caution: "simultaneous multi-user access" and MS-Access don't go well together. MS-Access if fine as long as you stick to single user. Try to get a more suitable database, for example PostGres, MS-SQL Server, or even MySQL. MS-Access is known to regularily cause data corruption, with simultaneous multi-user edits. As for your approach... IMO you can have live updates on your data, as long as the user wasn't actually in the middle of editing it. At the least, you do need a central locking mechanism, making sure only one user can edit a particular field, or a particular record, at a time. Less intrusive would indeed be a simple indicator, that might look a bit like a colored LED, indicating whether the data shown is up to date (green) or stale (red).	[reply]
Re^3: Database Realtime by Anonymous Monk on Jul 03, 2004 at 15:59 UTC
That is something I did not know. I don't know access very well, the boss wants touse it because it is Microsoft. I willl have to have a chat with him and see if we could go the route of MySQL as I at least know how the one works. Thanks for all your help, at least I now know where I stand and what needs to be looked and done in order to make it work. NG	[reply]