Skip to main content

Hi,

I just encountered an unexpected problem with the MSSQL_SPATIAL writer.

I originally set a manual command ("exec some-stored-procedure-with-arguments") to define a spatial index and more, which err'ed because there was no primary index on the relevant table. That's fine and understandable.

As I really didn't needed a spatial index on the specific table anyway, I just switched the dropdown "Spatial Index Type" to "None", and reran the translation.

But the translation still failed in the same place, while trying to execute the now deselected and unwanted command.

It seems like the command was still present, and FME tried to execute it as such, even though the setup stated it shouldn't. This I believe to be buggy behaviour, the overall choice should not be overridden like that.

Cheers

 

Lars I.

Seems that this is a known issue (filed as PR#50727). I'm told that a workaround is "deleting the SQL statement then hit OK, then come back and re-set spatial index type to None" , but this is obviously not ideal.

So I will add a link to this thread in that problem report and increase the priority. Seems to me it should not be a huge deal to fix this one.


Seems that this is a known issue (filed as PR#50727). I'm told that a workaround is "deleting the SQL statement then hit OK, then come back and re-set spatial index type to None" , but this is obviously not ideal.

So I will add a link to this thread in that problem report and increase the priority. Seems to me it should not be a huge deal to fix this one.

So this one is now reported fixed in FME2018. If it's causing major problems for you right now, and you don't have a workaround, the best thing to do is contact our support team (safe.com/support) mention the PR number and ask if it can be backported to 2017.

 


Reply