Alex,
This is partially dependent on which version of Exponare you are trying this on as well as using live vs. linked tables. I have found that “live” tables (unless they are extremely small) put a significant performance hit on both Exponare and MI Pro . Try linking the tables and see if they work for you.
Mike
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en
Hey Guys,Morgan from Tonkin Consulting here. Just a quick one and a minor correction, we have had the best results with SQL Server and Exponare by using data that is in Lat/Long on either GDA94 or WGS84 and storing it as a Geometry data type.
There are numerous other tweaks and customisations which need to be undertaken to get it all working correctly and optimally, but ultimately, they are dependant on the environment that you are implementing within.
Hope this helps somewhat.
Cheers...Morgan
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en
SQL can be a bit particular with field names when up loading using the Easyloader from Pro – you may discover some naming convention errors
· Make sure there is an ODBC connection to the SQL Server Spatial database
· In the workspace manager, open the tables through the ODBC connection
· If not working also ensure the MWS workspace file has the appropriate DNS connection strings
· Ensure Exponare has the appropriate levels of security to SQL Server – including machine names and the like
· Make sure all tables in SQL have been made mappable via the MAPINFO.MAPCATLOG ta ble (usually done automatically with the Easyloader) but can be skipped if using other methodology
· General syntax for joint data binds and queries et al need to be understood by SQL Server
Cheers Alex, hope ti goes well. The rewards at the end are worth it!some more direction here from Pitney Bowes would be great.
We think a mix of live reads, cached .TAB files and linked tables will work best in their case. Provided there is a business rule in place that SQL is the "god" then the duplication of data is negligible.
Using MGA does slow Exponare down in our preliminary testing.
There are some variables for the MARS and DLG settings
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en
Hi Guys,
Is Easyloader placing a value for your problematic tables in mapinfo.mapinfo_mapcatalog.symbol?
If the SYMBOL column for your problematic table is vacant you may not be able to read the layer from the DB with the Workspace Manager.
Copy paste the value from the MI_STYLE of your source (problematic) table (something like “Pen (1, 1, 6316287) Brush (2, 16777168, 16777215)”
Refresh the DB and let me know if the layer can now be read by Workspace Manager.
Cheers.
Regards,
Mathew Linnane
Pitney Bowes Software
And in the MAPINFOW.PRJ file there is a line:
2012/11/8 Alex Leith <alexg...@gmail.com>
Hi all
On Wed, Oct 31, 2012 at 2:49 AM, Eric Blasenheim <eric.bl...@pb.com> wrote: