A couple of weeks ago I asked for advice on how to build in multi-user user support for tables in a mapbasic application I'm considering. Thanks to Robert Crossley, Mark Ogilvie, Anssi Joutsiniemi, Peter Elphick, and Sue Port for their advice/commiseration! Unfortunately, there's few good answers. Basically MapInfo locks entire tables when there are edits pending. Others are still be able to read the table while edits are pending, but they cannot edit it at all. I've tried opening a table from two terminals in a network and this is the behavior I've seen in 5.5 using manual edits on records in the same table. When one terminal makes a change the other can do no edits. When terminal 1 save edits, terminal 2 can make changes, which then lock out terminal 1 until those edits are saved. Both terminals can read the table at any time. As soon as changes are posted from one, the other sees them whenever it next refreshes the browser or map window. These were with native MapInfo tables. Getting clever by trying to "set table... fastedit on undo off" will act pretty badly on reads too. Robert Crossley says Access tables get locked completely, even as read-only. This is true. Total lockout, whether opening as a Tab file or as Access table. I've tried this with v. 5.5. Another suggestion was to use ODBC connections. Well, this *may* work, but only in certain cases. With ODBC you link to a table and then each user gets a local copy of the linked table to edit as they please. The process is manual and so updates have to be handled specifically. Map data is a problem if it is anything but points (which can be dynamically linked as lat/long coordinates in table columns.) But in my case, I need lines and regions, so as Mark Ogilvie put it, "If the map objects are not points, and you can't get your hands on a gis-enabled RDBMS, you're stuck really." Sue Port suggested I look at Edit Plus from Spatial Plus (http://www.spatialplus.com/products.htm). This is a tool that allows you to create a customized edit dialog for your tables so that multiple users can edit and change data in native mapinfo tables. You can download a free demo (fully operational except that edits are not actually saved.) Except for add, delete move and copy, you cannot edit objects with this; only data (correct me if I missed something here Sue!). So, this won't work for my application, but it looks like a good possibility for data-oriented applications. Also it is for end-users. It can't be embedded in a custom application. Good solution, but it doesn't really solve my problem. Very nice demo though. Now I know where Atlantis is. Peter Elphick uses a lock table strategy which he reports works well (but not 100%). In his words: "This is an MS Access table in which a user must record his ID before the application allows him to write to the Mapinfo table. After the user has fininshed editing the MI table, he then clears the lock in the access table. Only one user is allowed a lock at a time so in theory you have multiuser access to the MI table. I back up the locking strategy with use of Mapbasic error trapping and doing all data capture to a temporary MI layer, then only updating the master layer when the geographical editing is complete." Although this is a lot more work than I hoped it would be, this looks like the best way to go. Essentially you have to write your own multi-user access functionality layer, and rigidly control when and how anything gets edited. This also means locking up the map and browser windows so inadvertent user edits don't set up a pending edit situation and bring your system to a halt. You do this through the command "Set Table..." and set "UserEdit Off". Then for any edits that need to be done, your app must provide the tools. Through these tools or procedures, you make edits on a copy of the record data or object and lock the table, write the change and commit the table immediately thus avoiding the problem of long pending edits. You still have to watch out for collisions, but if your app totally controls when tables are altered, and your coding is well-coordinated the locks are on only briefly, and nobody has to wait too long. So that's about it. Kind of looks like this is going to be an epic. If anyone has any better ideas I'd love to hear them. - Bill Thoen ---------------------------------------------------------------------- To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put "unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
