Your suspicions are correct. In general, there is no need to dump data into Access files, except as a quick way of providing portability (e.g. so someone can take a copy of a few tables on a machine which is not running SQL Server.)
MI with SQLServer is a no-brainer. Even if your application is written in Access, you can point it to a SQLServer database for its data. If your programmers don't know how to do these things it's not because it's too difficult for them -- it's just that they've never tried. As to MapInfo, I suggest that you simply try yourself -- just create the .TAB with your join, and point it to an ODBC DSN for your database. (If you need to create one, use ODBC Administrator, which is either on the Control Panel or on Control Panel | Administrative tools, depending on OS. Create a System DSN, and make sure to use the SQL Server driver.) BTW, there are two parts to ODBC. The functionality supplied by the idea of "Drivers" is critical. It is basically a middleware interface standard which allows many different DBMS vendors to plug in as back ends to many different applications. There are required calls defined, as well as optional features which depend on the DBMS capability. The other part is the concept of "Data Sources", which is pretty silly, even if it's trivial. This was defined in the early days, when MS had the idea that totally unskilled end users could somehow manage to utilize an application with a wide variety of different DBMS back ends, without knowing anything about the databases themselves. Therefore, they have this little catalog where you can make an entry for a "Data Source", and supply all of the parameters for a connection. Then, in the end-user application, you "only" need to pick the source. Of course what that really means is that if you wish to connect to an alternate source, you've got to go to the ODBC Administrator function and add it, and then go back to your application and pick it. For this reason, most users supply the connection info directly to the application, bypassing the Data Source business. I'm relatively new with MI, so I'm not sure whether you can do that in the interactive app (I'm using integrated mapping), but either way, it's a 15-minute head-scratcher, not a show-stopper. Fletcher James President Levit & James, Inc. 703-771-1549 [EMAIL PROTECTED] www.levitjames.com -----Original Message----- From: Doug Pease [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 1:34 AM To: [EMAIL PROTECTED] Subject: MI-L MI and SQL Server Hi Esteemed Listers, I'm interested in communicating with someone who has had experience using MI with SQL server applications. Is it possible to query data stored in an SQL server application, directly from MI. I imagine that DBMS ODBC drivers need to be installed to make the connection. We now use software that uses SQL server to store and maintain Local Gov't data on. This software then dumps out flat tables into MS Access which the GIS is expected to get its data from. I would much prefer to get the data from the origin than have to uses MS Access and have to rebuild all of the table associations which often don't work correctly along with numerous other problems. The software developers claim they need to dump the data out to flat MS Access tables so that other applications, such as Crystal Reports, MapInfo etc can access the data. This doesn't make sense to me. Hearing other users experiences might help sort out what I need to do. TIA Doug Pease GIS Officer Livingstone Shire Council PO Box 600 Yeppoon 4703 Qld Australia Ph 07 49399957 Fax 07 49393290 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the originator of the message. This footer also confirms that this e-mail message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Livingstone Shire Council. --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 14256
