There's more to experience when you log in!
I found this, but it reckons I can solve the issue with Map Uploader. Unfortunately it is Map Uploader that has the issue
I've completely deleted the map and all the tables and attempted to upload from scratch, but no good.
There was an error while creating Named Layer 'xxx'
Server response: Error in reading file 'xxx'. Field count mismatch between columns found in DAT and expected columns.
Please consult the log file etc
The DAT files have been an issue all afternoon. I couldn't renamed or delete broken ones. At this point I'm restoring everything I worked on today and next week will create new tables instead of deleting unnecessary columns from existing ones.
I don't think there's a solution for this one, just pointing another bug.
Hi Rebecca, it seems the table structure is not the same of the NamedTable structure. I would suggest to delete the NamedTables of your tables from the Spectrum Spatial Manager. After this you can publish again using Spectrum Spatial Map Uploader from MapInfo Pro.
You should be able to see the structure within the ssa ?spatial manager at the named tables level, there should be a tab that shows the attribute columns of the uploaded resource, you can then find the column that is missing from your table. You should also be able to follow all links within spatial manager for the named layer to named table etc and see the current layer. If there are any issues the table will need to be removed from spatial manager and uploaded again. Other issues you can come across is if the table is referenced within an SSA spatial view layer, SSA should notify you of this though.
hope this helps, cheers
Is the table you are "uploading" with Map Uploader the same table that Spectrum is reading or are you working on a copy of the data? It sounds to me like there is a mismatch between what the Uploader is telling Spectrum and what Spectrum is seeing when it reads the table.
Hi ?Rebecca, on reading your issue again, it also sounds like your tab file didn't save successfully the last time you edited it (removal of columns)
You mentioned that it was also an issue with other dat files, I would ask your tech guys to check the ntfs permissions on your work folders where your tab files are located.
Just a thought, cheers
Thanks Peter, I'll get IT to have a look. Permissions do my head in, I'm admin on all the servers but sometimes that isn't enough and it's somewhere else causing the issue.
None of rest of the above helps at all. Yes I have completely removed all reference to the tables before attempting another upload.
And yes, I removed the column. Because it was unnecessary or junky. Why doesn't uploading a new version of the file fix it?
What it is telling me is that once I have created or uploaded a table, I cannot under any circumstance change the columns, ever again, even if I delete the table from the spatial manager before I attempt to re upload? That's ridiculous. There must be something wrong somewhere.
If you are sure your tab file is fine etc, save a new copy, close original and rename it to filename_old, then rename the new tab file and try again.
You could also try uploading to a new mapname in another location.(that creates a new version within the spatial repository including all references to named tables, named layers, labels etc)
Another check to run through is to make sure that your version of the map uploader tool matches which ever version of SSA you are running.
If you had it in previous versions of SSA I would download and replace with the version that is linked within your ssa, there are two versions available in my setup (ssa 12.01)it depends on the version of mapinfo you use.
Forgive me if you know all this info, just trying to help eliminate some possibilities.
Thanks Peter, all of it is worth a try!
I've had a few Map Uploader issues, so that's a really good place to start
I've also had all my files restored back to before the issue to start again fresh
Alright, I have had another crack and I'm still getting the error. It appears somewhere it is holding onto the old file or file information. I get the error mid upload, and when I check the spatial manager the table is there, but the columns are the old columns and not the new ones, no matter how many times I delete and try again.
So I saved a copy with a different name and it uploaded fine.
Hi @Rebecca Marks? I had very hard time while finding out the root cause for this. Thing that we need to check
I am pretty sure, You wont be getting this issue if you can check all these three cases.
Are you seeing the correct table structure when looking at the Sample Rows for the NamedTable in Spectrum Spatial Manager?
If this is incorrect you could try setting the table to volatile as this will force spectrum to read the new table structure
Hi @Rebecca Marks? ,
With this type of issue with the old data attribute definitions within the spatial repository returning, this is pointing to spatial repository permissions or cached responses; given that you no longer seem to be able to regenerate all files within the spatial repository.
You mentioned that you can upload the data with another table name, map name etc if you then alter the attribute columns in the tab file and upload again does the same error occur with the map uploader tool.
Hi @Duri Bradshaw even if the layer configuration is removed from the repository this is occurring, doesn't the volatile setting only affect the attribute columns definition of an existing table/layer.?
I'm really surprised that if you remove the named table, layer config from the spatial repository that you cant upload the table again with the same name etc.
I think this is moving outside the scope of this forum and is best handled by PB support, I'm sure they could do a remote session and look at pertinent logs and the repository itself, including the role permissions within the management console.
You may need to think about the last time you took a backup of your repository and the possibility the repository needs to be replaced.
@Peter van Dijk? I agree, removing and re-adding the layer should work and is a good idea, I was interested to know what Spectrum was seeing as it sounds to me like Spectrum is looking at the old version of the table.
It can't be looking at an old version of the file, the file path points to the right place.
All of my uploads are volatile.
I can delete all of the files from the repository, upload the file again from scratch (by itself or in a workspace) and it still shows the old column structure in the preview. I haven't tried doing it again with a new file.
I've just taken to renaming the file. I've wasted enough time on this issue and I'm under time constraints as it is. If I have time to go back to it later I'll mess around a bit and see if I can work it out.
Thanks everyone for your input.