+13
Truncating table `EESTITOPO.HYB_VOOLUVEED_75T_J'...
Failed to truncate table `EESTITOPO.HYB_VOOLUVEED_75T_J'. Table may not exist
However, when truncate is defined in the "SQL To Execute Before Translation" under advanced writer properties, then truncate operation succeeds.
Thank you,
Raivo Alla
Estonian Land Board
+13
I don't see any open issues about truncating and I just tried it myself using the Oracle Spatial writer. It seemed to work for me when I set the destination feature type format parameter "Truncate Existing Table" to yes.
I can make a support case for this if you don't mind sending us your workspace and log. You'll see an email from support shortly.
Thanks
Ken
+14
Hello,
thank you both for answers...
Things are quite weird still, as even if im lucky to truncate table now (still using ), still at some point translation gets slow - as fas as I can see, it gets increasingly slow just before writing to Oracle database at Clipper transormer... Or infact it could be writing to Oracle itself that is the bottleneck, cause process is not consuming much memory .
The weird part is that when I'm running that translation with workbench, I have no problems. But as I use fme.exe from batch file, i get those problems.
Is it possible that saving a workspace sometimes with FME 2011 and then again with FME 2012 may cause that horror?
Raivo
Hi!
Problem seems to be solved for now. I deleted and added Oracle writer again (under FME 2011SP4) and this time it seems to work fine, at least FME successfully managed to write to Oracle this time.
I tried this before, but as I have FME 2013 beta,2012 SP3 and 2011SP4 installations, Im not sure whether I redefined writer (without solving the issue) in 2011, 2012 or 2013 last time.
Raivo
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
