Import Solution Unsuccessful

Classic Servoy
1

Hi

I have one client using my solution who is trying to import my latest solution version with errors. They have imported solutions previously and been fine.

The server and client are on the same computer. The client and server seem to be working fine. The repository server and solution server are both online prior to import.

We have also loaded this solution version into other servers including my own with no errors.

This is the error message from the solution import.

Importing C:\Documents and Settings\Helen\My Documents\aerotrack install\AeroTrack build 56.servoy…
[info] Import contains XML version 10 and repository version 27.
[info] Imported style ‘newaerotrack’.
[info] Imported style ‘aerotrack’.
[error] com.mysql.jdbc.CommunicationsException: Communications link failure due to underlying exception: ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: Connection reset STACKTRACE: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1910) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2304) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2803) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573) at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1160) at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:685) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1400) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1314) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1299) at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.servoy.j2db.persistence.datasource.p.invoke(Unknown Source) at $Proxy0.executeUpdate(Unknown Source) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:207) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:207) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:207) at com.servoy.j2db.persistence.i.int(Unknown Source) at com.servoy.j2db.persistence.i.a(Unknown Source) at com.servoy.j2db.persistence.XMLImporter.importSolutionFromFileAs(Unknown Source) at com.servoy.j2db.persistence.XMLImporter.importSolutionFromFile(Unknown Source) at com.servoy.j2db.server.servlets.ConfigServlet.a(Unknown Source) at com.servoy.j2db.server.servlets.ConfigServlet.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106) at java.lang.Thread.run(Unknown Source) ** END NESTED EXCEPTION ** Last packet sent to the server was 282 ms ago.

After importing the server admin tool does not work and they can also not load the client. On reboot all works fine the admin tool and smart client work fine. We continue to get these errors on importing a solution however. Running mysql 5.0 for both repository server and data on both developer system and production system. Servoy is version 2.25 on production system and 2.26 on my development system.

Seems to be straight connection errors but prior to the import client and server work fine?

Have never had these errors before so would appreciate advice. Client did perform large number of windows updates this week, maybe causing issues?

2

Anyone?

3

Hi Rodney,

While you’re waiting…
Instead of importing, you could in an emergency just replace the whole repository using whatever tool you use to work with mySQL.

We had to do this moving from 2.2.x to 3.0.0 because of a bug which prevented import.

4

Thanks Christian

5

Hi

Have noticed that as soon as i start the import whether through Developer or Servoy Admin that it stops the MySQL service!

This would explain the errors as there is no database to connect to/update and why after the unsuccessful import i can no longer connect to the admin and/or run the client

Why would starting the import in Servoy stop the the MySQL service?

Any help would be appreciated.

6

MySQL just stops…you mean MySQL crashes? Or is it just that the connections that Servoy had with MySQL go deaf?
Any MySQL logs on the server ? Or anythying in the system/event log?

7

Hi Robert

Thanks for your help.

The MySQL service stops. I can see this clearly as i have a WAMP server installed and can see the service stop during import from a system tray icon. I have to restart the service to get everything going again.

The log above was copied from the .service_log file in the servoy folder.

This is the only installation that does this. Other have upgraded to the latest solution version successfully.

8

Have you installed the latest JDBC driver?
Make sure you do have the latest version.

9

Hi Robert

Driver is 5.03 i think now its 5.04 but other servers are running fine.

I am starting to think this has something to do with anti-virus software! User has just updated anti-virus today and client is now not working. I will log on remotely tomorrow and have a look. He is using PCillin not sure if others have had issues with this?

Thanks for your reply.

10

Hi

Did a reinstall and seem to have got around this issue.

Can anyone tell me why the following occurs?

when i export a solution from my development system all number dataproviders are either “double” or “float” type. When i import solution to an empty system it changes the “float” types to “decimal” datatypes! This causes a host of issues the least of which i get a lot of warnings on the import solution page. I can change these back to “float” which remedies future imports but i’s not reassuring doing backups/restores and then reimporting solutions.

All systems have identical servoy versions, java versions, MySQL versions, and JDBC Drivers.

11

rodneysieb:
Can anyone tell me why the following occurs? …

I’ll give it a shot, to the best of my understanding. Apologies in advance if any of this is off-base and thanks in advance to anyone who steps in to correct anything I write below…

when i export a solution from my development system all number dataproviders are either “double” or “float” type.

When you say the data types are “double” and “float” you mean, I take it, that you used a tool other than Servoy to define the schema for the MySQL back end.

These are not data types available when creating columns via Servoy’s Define Dataproviders interface. The only numeric choices in the DD dialog are “number” and “integer”. Why? (The following “answer” is pure theory so I’m a bit out on a limb, but I’m pretty sure it will hold up…)

If you look at all the data types across the numerous back ends that Servoy must play with, this varies pretty widely, perhaps most of all among the date/time/datetime and number-related data types. One platform’s Boolean is another’s tinyint (which is not really Boolean), for example. One will have a “money” data type and another won’t. One will have datetime, timestamp, date, time and year types; another will have only date, timestamp and time.

Because Servoy Developer provides a way to create back-end tables and columns using a front-end design tool, I suspect that the “flattening of the data types” into a short list of five major types has to do with the fact that there would be no way to address the wealth of different data types across all the back end platforms that are in wide use. So if we define a solution’s back end via Servoy’s DD dialog, we are offered some broad data-type categories, not very specific data types. When we click Apply in the DD dialog, Servoy sends the SQL to the back end to create the defined columns, and probably has some standard data type it will create for “number” depending on what back end it’s talking to. .

When i import solution to an empty system it changes the “float” types to “decimal” datatypes!

What do you mean by “an empty system”? If you mean that you have simply created a named db on the back end but are letting Servoy Server create the tables and columns upon import of the repository, Servoy does not recreate the finer points of back-end design that you can specify when you use a back-end tool.

You may have noticed on your development box that Servoy was “reading” both your “double” and your “float” columns as simply “Number”. So if you ask Servoy to re-create your back-end schema upon import of the repository for an “empty system”, you need to plan for the fact that Servoy will adjudicate as best it can between its own 5 data types and the available data types of the back end server environment. I’d wager that for MySQL Servoy by default creates “decimal” fields on the back end for what it calls “number” on the front. (I have not worked with MySQL yet via Servoy’s DD dialog … maybe someone here can correct me if this theory is wrong.)

This causes a host of issues the least of which i get a lot of warnings on the import solution page. I can change these back to “float” which remedies future imports but i’s not reassuring doing backups/restores and then reimporting solutions.

I’m not sure why you would need to have Servoy re-create your back end from scratch if you need to restore from a back up. Just restore the back end too … but apart from that, and back to the broader topic:

We do inherit a good deal of responsiblity as Servoy devs to understand that if we fine-tune a particular back-end environment using a back-end tool, we cannot expect Servoy to recreate that fine level of detail (never mind data types, how about relational constraints?) by simply importing the repository. If you wish to use back-end-specific data types or define relational constraints or indexing particularities on a back end by means of importing a Servoy solution on the application layer, you would need to write the SQL commands yourself (in a method) that fix up the back end exactly how you want it. Otherwise be prepared to either stick to Servoy’s data types, or to use a back-end tool to tweak things directly.

All systems have identical servoy versions, java versions, MySQL versions, and JDBC Drivers.

Sure, but Servoy does not have identical data types with MySQL. That’s the rock you’re stubbing your toe on.

kazar

12

Hi

Many thanks Ilyse for your reply.

The main issue i had was that creating a number field in Servoy seems to be creating a “float” type field in MySQL, fine. When you export that servoy file and then import it into an empty MySQL database via developer to build the solution for the first time it creates “decimal” fields. I was hoping that servoy would be more consistent in that the field types it creates in developer as an export file is what it creates on import of solution.

I need to create new databases often with a vertical market solution that i sell. I will obviously have to pay much more attention on fine tuning the database fields using backend tools.

Thanks again.

13

Sorry for my presumption that you must’ve used a back-end design tool to create the float column. It certainly does not seem right if Servoy is choosing data types in a random kind of way when the back-end and jdbc driver are both the same…

kazar

PS: You might want to triple-check the MySQL versions. I do remember reading that something broke between 4.1 and 5 with regard to how decimals vs. floats are handled. It seems a remote chance, but maybe this is somehow affecting the data type Servoy ends up creating?

14

Hi all

thought i would raise this one again as it has me stumped.

My customer cannot import a new version of the solution.

The solution runs fine but when i try to import a new version it stops/crashes the mySQL service! i thought this might be a faulty/corrupted/antivirus/spyware windows XP issue so i have left it alone. This client has now done a complete new install of windows XP (SP2) no antivirus/spyware installed yet. I reinstalled the application identical to my dev system and identical to every other system i have ever installed. Installation was perfect and imported correctly, imported again and all was fine.

I restored the users data and now again on import of a new version causes the mySQL service to stop!!!

I have tested this users data in 2 other hardware systems (including my notebook) again all versions servoy identical and the import will work properly. This is my only production system not allowing import of a new version.

Would appreciate any clues as to why this is happening? Must be some sort of hardware issue. Driver issues, port conflicts etc. Should i try shifting off port 8080 as default? Client is using AMD 64 CPU - any known issues?

Again all versions always the same. Servoy 2.25 JDBC driver and MySQL 5.027