Jonathan / Hendrick I have solved the problem excatly like you. At any rate, is not a good solution when you need to work with large tables (I have table with more than 500.000 records). Once we extract an area with its objects and after these objects are modified in other PC, you need to "consolidate" them in the master table. The only safe way to do this is using a StoreProcedure. The problem is that inmediatly you need to make a "refresh" to see the table updated, and with big tables, the refresh can you several, several, several minutes !. If you don't make a refresh, the local copy (linked table) is diferent from the database, so you will see masages continuously indictaing you these diference. Other interesting way is to do the same but without a PC with the entrie sytem opened. So, from others terminal, the users can select the work area and lock these records in the database. These records are download in a local copy (linked table) and the updated are inmediatly saved into the database. In this case is not necesary to make any refresh becuase any PC has the entire system opened. User who need to make queries, analysis, etc must to work with a MI Local/Server copy, so all proccess will be faster. My AM/FM aplication work like this.
Another way (and it has not comparation with MapInfo) is to use ESRI technology with Arc/SDE. Regards Alejandro - Argentina ----- Original Message ----- From: "Stokes, Jonathan (J)" <[EMAIL PROTECTED]> To: "'Possberg, Hendrik (Fa. Microm)'" <[EMAIL PROTECTED]>; "'Mapinfo-List'" <[EMAIL PROTECTED]> Sent: Wednesday, July 24, 2002 8:05 AM Subject: RE: MI-L Multiuser capacity? Hendrick I've been struggling with this problem for a few weeks now. MapInfo does not allow multi user editing. From my experience this situation should be avoided at all costs. When carrying out edits MI creates three temporary locking files (.TIN, .TDA, .TDA) that contain the edits. When the user hits the save button these edits are committed to the main table and the locking files disappear. Another user can now interact with the table. In such a situation it is however possible to cause a large number of problems within the table. MI is not very sophisticated at storing referential integrity between it's map objects (in the .map part of a table) and the data files (the .dat part of the table). It is possible to "break" this referential integrity in such a situation. This leads to the table being corrupted and the loss of data. We're looking at using spatialware and it is being experimented upon - but it will allow multi-user editing. In the mean time we have implemented a manual system whereby we have a master table and create extracts from it and allow people to work on those individual extracts before putting them back into the main table. Regards Jonathan > -----Original Message----- > From: Possberg, Hendrik (Fa. Microm) [SMTP:[EMAIL PROTECTED]] > Sent: 24 July 2002 11:53 > To: 'Mapinfo-List' > Subject: MI-L Multiuser capacity? > > Dear list, > > I am wondering if any changes according the "multiuser capacity" between > Mi 6.0 and 6.5 occured. > I remembered that 2 editors could work in one table and sometimes the > table was "blocked" when both wanted to write > -but after a few seconds the table accepted the input. > Now we have MI 6.5 and its not possible to change anything in the table > neither for editor one or two. > > My Question is: > -How can we achieve it to work and save with more than one editor in one > table? > -Would the usage of MI Spatialware prevent this constraint? > > > Mit freundlichen Gr��en > > microm > Micromarketing-Systeme und Consult GmbH > > > Hendrik Po�berg > Data & Methods > > Hellersbergstr. 14 > 41460 Neuss > Phone: 02131-10 97 51 > Fax: 02131-10 97 77 > mailto:[EMAIL PROTECTED] > www.microm-online.de > > Diese Nachricht wurde elektronisch versandt und ist daher auch ohne > Unterschrift rechtsg�ltig. > Der Inhalt dieser E-Mail enth�lt vertrauliche Informationen. Das Kopieren > und die Weitergabe > an Dritte ist nicht gestattet. Sollten Sie diese E-Mail irrt�mlich von uns > erhalten haben, > bitten wir Sie, diese zu vernichten und uns dar�ber zu informieren. Im > Voraus vielen Dank. > > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
