On Mon, 09 Feb 2004 10:57:23 -0700, Bill Thoen <[EMAIL PROTECTED]> wrote:
The trick seems to be to design an application/environment where the tables being edited by multiple users are opened for writing for as short a time as possible, and that all applications that access these tables are prepared to retry or cancel read and write operations intelligently. Do this correctly and your system shouldn't cough up its socks even if someone opens a tab file interactively and starts to monkey around with it. At worst, your application should just let users know that a table is locked by another user and either try again or quietly back up and let you do something else.
I have an application that does this reasonably successsfully. You have to extract the edit data out of the master file before you edit (but you could just copy and update a "being edited" tag), and then add it back when your finished. To do this while other people are using the table requires locking the master table in deny write mode, so I have a function that tries to open thetable in whatever mode, and if it fails, you can take the appropriate action.
In the code when I want to add files back to the master table, I use:
If Not fOpenTable(TABLENAMEANDPATH, "", "DenyWrite") Then
Note "Could Not Open Table TABLENAMEANDPATH exclusively, please ask other users to exit before continuing."
Exit Function
End If
Add edits as needed.
Close Table then
If Not fOpenTable(TABLENAMEANDPATH, "", "ReadOnly") Then
Note "Could Not Open Table TABLENAMEANDPATH."
Exit Function
End If'This tries to open the table in exclusive mode, and if it fails just tells the user to try again later. It is a pain when you have the table in a map and you have to reconstruct the map etc as well.
The open table function is as follows.
Function fOpenTable(ByVal sFileName As String,
ByVal sTableName As String,
ByVal sMode As String) As Logical
'-----------------------
'Subroutine: fOpenTable
'Called By:
'Description: This subroutine
'Written By: RC
'-----------------------
OnError GoTo ErrorHandler
fOpenTable = FALSE
If sTableName = "" Then
sTableName = PathToTableName$(sFileName)
End If
Call DISPLAYMESSAGE(MSGLEVEL_DEBUG, "Starting fOpenTable Function to open " + sFileName + " as " + sTableName)
Do Case sMode
Case "Normal"
Open Table sFileName As sTableName interactive
Case "DenyWrite"
Open Table sFileName As sTableName DenyWrite
Case "Readonly"
Open Table sFileName As sTableName Readonly
Case Else
Note "Incorrect variable for sMode"
End Case
If TableIsOpen(sTableName) Then
Call DISPLAYMESSAGE(MSGLEVEL_DEBUG, "Opened " + sTablename + " (" + sFileName + ") in " + sMode + " mode.")
fOpenTable = TRUE
Else
Call DISPLAYMESSAGE(MSGLEVEL_INFO, "Table " + sFileName + " could not be opened as " + sTablename)
Exit Sub
End if
EXIT Function
ErrorHandler:
Print "Error opening table " + sTablename + " (" + sFileName + ") in " + sMode + " mode."
End Function
[EMAIL PROTECTED] wrote:2. Performance of the TAB file - you'll need to pack it often to ensure that
the spatial indices don't get knackered (technical term)
Knackered? Is that the same as the Canadian english 'hosed' or the American english 'fubar?' And who knows how the Aussies say it, but I bet it's colorful!
But seriously, there's a section in the MapBasic Users Guide called "Multi-User Edits" that's worth a read for anyone whose about to wade into this swamp. Apparently MapInfo thinks we can do it.
The trick seems to be to design an application/environment where the tables being edited by multiple users are opened for writing for as short a time as possible, and that all applications that access these tables are prepared to retry or cancel read and write operations intelligently. Do this correctly and your system shouldn't cough up its socks even if someone opens a tab file interactively and starts to monkey around with it. At worst, your application should just let users know that a table is locked by another user and either try again or quietly back up and let you do something else.
Performance is always an issue with MapBasic, and usually some form of local temporary tables are needed to edit existing objects without tying up the whole table. It gets tricky when posting edited objects back to a table because not only do you have to update just those that have changed but handle new and/or deleted records as well.
I think the hardest problem to solve is to write an application so that it can tolerate 'access denied' situations and be prepared to go to Plan B if necessary. Or handle a power failure where recovery may require resetting file & record locks set previously by the application. These are simply multi-user edit issues and have to be dealt with no matter what DBMS you're using. Imagine the fun we'll have in the near future when tables are scattered across the Internet and our applications must run 24/7 and communications failures have to be reckoned with as well!
- Bill Thoen
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10333
--
Robert Crossley Agtrix P/L 9 Short St New Brighton 2483 Far Southern Queensland AUSTRALIA
153.549004 E 28.517344 S
P: 02 6680 1309 F: New Connection M: 0419 718 642 E: [EMAIL PROTECTED] W: www.agtrix.com W: www.wotzhere.com
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 10339
