I'm a Manifold newbie helping out a client and I've worked on this one a bit long!

We have a MySQL database which I can import and geocode as expected.

But when I try to LINK it (Because I want the generated lat/longs back in the database) I have problems.

It seems to link and it adds the columns (I specified new columns for lat/long/match and status).

But then I get a message window/box, "Can't Modify Table Cell" and there will be no data in the new columns

I've tried playing with the ODBC settings, etc. But if it can modify the table shouldn't it be able to modify a cell? I have MySQL admin and gave the ODBC username full rights.

Any ideas? THANKS!!

I reported this issue to tech a while ago, as I experienced similar problems. The solution is to use the "OLE DB Provider for ODBC sources" and not the ODBC connector directly. Their explanation follows:

Both Manifold and the Microsoft OLE DB Provider for ODBC only consider an ODBC data source read-write if it exposes a read-write cursor that matches certain requirements. Manifold's requirements are stricter than those of the Microsoft OLE DB Provider and so some ODBC data sources are considered to be read-only when accessed directly from Manifold and read-write when accessed through the Microsoft OLE DB Provider.

We are planning to relax the requirements we use to evaluate the cursors exposed by ODBC data sources in future versions of Manifold.

I always use the OLE DB provider for MySQL sources.

Thanks to your info and another thread of yours ( http://forum.manifold.net/forum/t43878r43945#r ) I got things working and the Table/Address/Geocode command works.

Except: at the end of the run the exceptions panel displays for manual intervention of those addresses it couldn't figure out. If we click on Accept for any of these, I get the dreaded "Can't Modify Table Cell" message.

Even though it just got finished modifying a whole bunch of them.

I'm using Microsoft OLE DB Provider for ODBC Drivers, MySQL ODBC 3.51.21.00 driver, MySQL 5.0.37-community-nt.

I see MySQL ODBC 3.51.23 is on the website and will give that a try. But I suspect something else is going on since the driver I have works for the initial run.

Thank you for any ideas!!

What is the schema of the table on MySQL? Could you post your MAP file? As a temporary workaround, consider importing all data from MySQL into Manifold, performing the geocoding, then exporting the result back to MySQL.

Instead of posting the entire schema, I created a smaller table to test and got the same results. The schema I attached shows the Latitude, Longitude, Match Type and Status fields as created by Manifold.

If a lat/long column is populated, Manifold will pop the error, "Can't Modify Table Cell". If I start by setting both columns to null, the geocoding works.

Until it gets to the exceptions. Anytime I click on Accept, I'll get the "Can't Modify" message. I assume this is because the initial run of the geocoding has now populated the exception records with 0's.

I can do nothing but exit out of the exception window. I don't see a way of getting back in to the exceptions window without running the initial geocode which puts 0's in the columns for which the exception process "Can't Modify".

The actual table is 1meg+ records. Importing/exporting a subset of those records (we only need to update a subset at a time) is cumbersome but possible. It just seems like linking should work and would provide the least disruption to shared database access.

The "Can't Modify" and the behavior described above occurs:

1. Whether I use an existing column or specify Manifold to create a new one. Or if I specify the same column Manifold created in the previous test run.

2. Use MySQL or InnoDB

3. Use a small sample table or the larger 60 column table.

Thanks again for the help!

Attachments:
sites.map
SitesSchema.html

We have investigated and it looks like at least the combination of MySQL 5.0.45, MySQL ODBC driver 3.51.16 and the Microsoft OLE DB provider for ODBC has problems setting floating-point values. We will try with the latest version of MySQL ODBC driver.

Great! I mean not so great there is a problem, but GREAT that you were able to duplicate it.

It only seems to be a problem if the field is NOT null. If it has any value it in, 0, or anything, a new value cannot be written.

Looking forward to any info you can help with!

Thanks!

Scott

We have tried using the latest version of MySQL ODBC driver and it exhibits the same problem as 3.51.16. Attempting to update a row fails if the new value of one of the fields being set coincides with the old value. This can be reproduced without Manifold. To work around the problem during geocoding, reset the values of the fields you will be writing to (Latitude, Longitude, Status and Match Type, unless you turn some of them off via the relevant combobox) in the records you want to geocode prior to performing the geocoding operation.

could the last driver3.51.25 instead 21 two months after this post resolve the problem ?

UGH! No changes (that I know of) and now I'm receiving the "Can't Modify Table Cell" every time.

This is a little frustrating as I wish I were way past this and having fun with Manifold. not.

Thanks for any more suggestions. Perhaps I need to get away from MySQL (did I say that?)?

Sorry to keep bugging you but wanted to let you know I'm back to step one. I can usually do the Table/Address/Geocode command though some combinations of "new column" vs. specifying an existing column for lat/long updates don't work.

I'm consistenantly getting the error at the end of the run on the exceptions panel. If we click on Accept for any of these, I get the dreaded "Can't Modify Table Cell" message.

I tried using MySQL ODBC 3.51.23 but now I'm back to .21

I'm using Microsoft OLE DB Provider for ODBC Drivers, MySQL ODBC 3.51.21.00 driver, MySQL 5.0.37-community-nt.

Thanks

Hello

Have you solve your problem?

Regards