There's more to experience when you log in!
Jenny,I am glad that your situation is working but as Technical Product Manager, I need to ensure that the information on this community is correct and does not imply unnecessary actions by our customers. Clearly we need to make this more understandable so that this would not occur.First of all, titles matter and this thread has absolutely nothing to do with fonts. I hope that future visitors would not find that and think it did. Maybe we can change it to "Handling volatility of Named Tables"Secondly, when a error about a column not existing appears, it is either because the named table is pointing to a different version of the table (which was my first idea) or because the table changed, then named table was set to non-volatile which to the server means you have declared it won't change.David Murphy was basically correct when he said "Even if you delete all reference to the table in Spatial Manager it seems to remember it elsewhere which will mess things up if the slightest modification has been performed on your table." This is true if the Named table is non-volatile which means it will not change.Technically what this means that IF the named table is marked as non-volatile, (volatile false) then the server code caches all the information about the TAB file (or database table) in memory for performance reasons; note not on the named table, the actual data source. See more below.The table is supposedly not changing so that is what we do and this really helps with performance for map tiling/rendering and heavy querying. We want folks to keep tables non-volatile whenever possible.The key then is how to get Spatial to forget about this information and read anew from the table. This could be a column change, even just its name, a change to the spatial data that has caused an index change and probably others. So if the data has changed, the data is volatile.As David mentioned, toggling the named table to volatile (and back) should do the trick. I will post back if I can find cases where this is not true.In version 18.2, there is a restart button under settings. This will clear all caches as the spatial piece is starting over. If you are doing bulk changes to the data, it is recommended to use this after applying the data . This should happen when the server is not in heavy use.This way you can keep the data non-volatile for performance and only flush our cache when necessary. Restarting just spatial is not time consuming and much faster than a complete Spectrum restart.Currently the map uploader always sets the tables to non-volatile. This was in response to many performance complaints. I now believe that we have to expose this via the uploader so that people can choose. However, I think that there are ways to maintain performance for data that is only changing occasionally.Summing up you should never have to copy the data to a new name or folder in the repository to make any of this work.Jenny, you said :"It is interesting because I had removed the folder/links in Spatial Manager several times but it appears that when uploading it was not overwriting it as you mentioned James"The comment about the internal cache on the table and not the named table, is why you can delete the named table and still have this issue as the code remembers the data source. Hopefully you have one named table for that data. That is the idea. If you delete the named table and redo the upload which recreates it, the internal code still has the same old cache. So again, got to get rid of that cache.I have some thoughts of things we could change in the uploader but I really don't want to start that discussion on a thread about"fonts". I will start a new and love to hear your thoughts.