Servoy 5.1.2
I need some help deciphering the failed solution import message below:
The error:
com.servoy.j2db.persistence.RepositoryException: Column ‘an_id’ in table ‘an_syns’ for connection ‘arm_data_vfp’ does not exist and could not be created.
complains about a column that doesn’t exist, yet three lines above, it says the same column was created:
Added column with name ‘an_id’ to table ‘an_syns’ in server ‘arm_data_vfp’.
Why the discrepancy in messages?
Thanks!
kwpsd:
Servoy 5.1.2I need some help deciphering the failed solution import message below:
The error:
com.servoy.j2db.persistence.RepositoryException: Column ‘an_id’ in table ‘an_syns’ for connection ‘arm_data_vfp’ does not exist and could not be created.
complains about a column that doesn’t exist, yet three lines above, it says the same column was created:
Added column with name ‘an_id’ to table ‘an_syns’ in server ‘arm_data_vfp’.
Why the discrepancy in messages?
Thanks!
Can you check the servoy_log.txt file and post here the whole error(s) - with stack ?
Due to the import problem, we instructed our customer to re-install Servoy, and, in the process, the error log was deleted. However, I have an error log snippet from the week before showing the same error. Note that this is the same error I reported in the following thread:
http://www.servoy.com/forum/viewtopic.php?f=8&t=14023
Below is the log snippet:
2010-04-16 16:25:42,329 ERROR [http-8080-1] com.servoy.j2db.util.Debug - Throwable
com.servoy.j2db.persistence.RepositoryException: com.servoy.j2db.persistence.RepositoryException: could not update columninfo, column has none
at com.servoy.j2db.server.xmlxport.Zp.Za(Zp.java:37)
at com.servoy.j2db.server.xmlxport.XMLImporter.Za(XMLImporter.java:30)
at com.servoy.j2db.server.xmlxport.XMLImporter.importFromJarFile(XMLImporter.java:12)
at com.servoy.j2db.server.servlets.ConfigServlet.Zj(ConfigServlet.java:1096)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:2465)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: com.servoy.j2db.persistence.RepositoryException: could not update columninfo, column has none
at com.servoy.j2db.persistence.Zvd.Zb(Zvd.java:294)
at com.servoy.j2db.persistence.Zvd.Zb(Zvd.java:23)
at com.servoy.j2db.persistence.Server.updateAllColumnInfo(Server.java:216)
at com.servoy.j2db.persistence.Server.syncTableObjWithDB(Server.java:671)
at com.servoy.j2db.persistence.Server.syncTableObjWithDB(Server.java:374)
at com.servoy.j2db.server.xmlxport.Zo.Zb(Zo.java:777)
at com.servoy.j2db.server.xmlxport.Zo.Za(Zo.java:662)
at com.servoy.j2db.server.xmlxport.Zp.Za(Zp.java:119)
… 18 more
More info…
The solution that our customer was trying to import uses Visual FoxPro tables, not SQL tables. We discovered that the offending VFP table had its Unicode Code Page value set to 10000 which we believe is undefined. When we changed the code page value to 1252, then the import succeeded. After the failed import, we could view the table data in Servoy Developer, but its column names were displayed in the Greek alphabet, and the data was undecipherable. So, there must be some correlation between a successful import and the code page value. Does this help?
Edit Clarification:
My mistake…the import was not successful! It got past the table with the code page problem, but is now hanging up on another unknown file:
2010-04-26 15:59:21,727 ERROR [http-8080-1] com.servoy.j2db.persistence.Server - java.sql.SQLException: An unkown sql type: -80298029
2010-04-26 15:59:21,774 ERROR [http-8080-1] com.servoy.j2db.util.Debug - Throwable
com.servoy.j2db.persistence.RepositoryException: com.servoy.j2db.persistence.RepositoryException: java.sql.SQLException: An unkown sql type: -80298029 An unkown sql type: -80298029
at com.servoy.j2db.server.xmlxport.Zp.Za(Zp.java:194)
at com.servoy.j2db.server.xmlxport.XMLImporter.Za(XMLImporter.java:6)
at com.servoy.j2db.server.xmlxport.XMLImporter.importFromJarFile(XMLImporter.java:12)
at com.servoy.j2db.server.servlets.ConfigServlet.Zj(ConfigServlet.java:3042)
at com.servoy.j2db.server.servlets.ConfigServlet.service(ConfigServlet.java:2145)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: com.servoy.j2db.persistence.RepositoryException: java.sql.SQLException: An unkown sql type: -80298029 An unkown sql type: -80298029
at com.servoy.j2db.persistence.Server.initTable(Server.java:1378)
at com.servoy.j2db.persistence.Server.initTableIfNecessary(Server.java:762)
at com.servoy.j2db.persistence.Server.getTable(Server.java:177)
at com.servoy.j2db.server.xmlxport.Zo.Zb(Zo.java:896)
at com.servoy.j2db.server.xmlxport.Zo.Za(Zo.java:347)
at com.servoy.j2db.server.xmlxport.Zp.Za(Zp.java:298)
… 18 more
We have no idea which table/file is causing the ‘An unkown sql type: -80298029’ error. I know that you stated you would include reporting of which table caused the error on the Servoy Server display in the forthcoming version 5.1.3, and I hope you are including it in the log file as well.
Thanks!
Not sure what happens here, seems to be caused by some VFP issues ? You said you can import the solution on your local computer. Do you have the same set up (database engine, driver … ) ? You could also take the tables from your client and simulate what happens on local computer. If you can reproduce locally it would be much easier to see what happens (also, then, if you think is a bug you can open a case and we’ll have a closer look). About the error: java.sql.SQLException: An unkown sql type: -80298029, unfortunately the sqlexception doesn’t say the table name, can you attach the solution here or send me by email ? I will check which column has this sql type.
Laurian,
Thank you for your offer to help us determine which data file is causing the problem. The data contains highly sensitive research information that belongs to our customer, and we are forbidden by the customer from diseminating that data…sorry.
We did find the second offending file by clicking on the ‘Update servoy sequences for all tables’ button on the Servoy Application Server Database Server page for the appropriate database connection. Once we knew the file name, we checked its code page value and discovered that it was set to 0 (zero). We changed the code page value to 1252, and the solution finally imported.
So, there are two issues that should need to be looked at:
When an solution import fails due to a file error, it would be helpful if the ‘servoy_log.txt’ reported the name of the offending file. (I know you previous said you would address this).
I don’t know if this is really a separate issue, but the import function is sensitive to the code page value of a file. I do not know enough about the import process but suspect that this may have something to do with the I18N Internationalization. Perhaps, reporting this could be rolled into #1 above.
Thanks again for all your help!