Servoy Developer "loses" database mapping after "Clean Build

Classic Servoy
1

In our application we use the databaseManager.switchServer to switch at runtime the database connection from one database to another “clone”. Unfortunately, in Servoy Developer sometimes we get the following errors after the following sequence of steps:
1 - start the debug the client, then stopping it,
2- updating the source code with latest version from SVN and using the “Refresh” option in the Solution Explorer
3- do a Clean Build
4 - starting back up the debug client:

2012-07-16 15:03     pool-4-thread-2     ERROR     com.servoy.j2db.util.Debug     null parameters: <null>     87B0AB76-8F1A-470A-8790-E1995756334B    argos_agile_client
java.lang.IllegalStateException: Could not resolve column argos_user_data:dbo:ab_user_settings#abusersettings715.1073773169=?
     at com.servoy.j2db.server.Za.Zc.Za(Zc.java:223)
     at com.servoy.j2db.dataprocessing.Zv.Za(Zv.java:1099)
     at com.servoy.j2db.dataprocessing.Zv.Za(Zv.java:511)
     at com.servoy.j2db.dataprocessing.Zv.performQuery(Zv.java:965)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.servoy.j2db.util.AbstractRemoteInvocationHandler.invokeMethod(AbstractRemoteInvocationHandler.java:72)
     at com.servoy.j2db.util.ThreadingRemoteInvocationHandler$1.run(ThreadingRemoteInvocationHandler.java:79)
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source) 


2012-07-16 14:56     main     ERROR     com.servoy.j2db.util.Debug     Could not register MBean           
javax.management.InstanceAlreadyExistsException: com.servoy.datasource:type=argos_user_data
     at com.sun.jmx.mbeanserver.Repository.addMBean(Unknown Source)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(Unknown Source)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(Unknown Source)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(Unknown Source)
     at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(Unknown Source)
     at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(Unknown Source)
     at com.servoy.j2db.datasource.jmx.ManagedBasicPoolingDataSource.initialize(ManagedBasicPoolingDataSource.java:28)
     at com.servoy.j2db.datasource.jmx.ManagedBasicPoolingDataSource.getConnection(ManagedBasicPoolingDataSource.java:33)
     at com.servoy.j2db.server.Za.Zo.getRawConnection(Zo.java:1126)
     at com.servoy.j2db.server.Za.Zo.Zf(Zo.java:1649)
     at com.servoy.j2db.server.Za.Zo.testConnection(Zo.java:239)
     at com.servoy.j2db.server.Za.Zc.testServerConfigConnection(Zc.java:453)
     at com.servoy.eclipse.ui.views.solutionexplorer.actions.EnableServerAction.setServerEnabled(EnableServerAction.java:96)
     at com.servoy.eclipse.ui.views.solutionexplorer.actions.EnableServerAction.run(EnableServerAction.java:83)
     at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
     at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
     at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
     at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
     at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
     at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
     at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165)
     at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754)
     at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
     at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
     at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
     at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
     at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
     at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
     at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
     at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
     at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
     at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
     at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
     at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
     at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
     at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
     at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

The errors are from the Server Log. After such errors the client’s behavior is basically unpredictable and we need to restart the Servoy Developer. The issue happens regardless the client - Smart or Web. After restarting the Servoy Developer, everything works fine as expected without making any changes.

What is causing this issue? Has anyone else experienced similar issue? Is this a bug?

2

does this really also keep happening when you really restart the debug smart client?
So really close the solution in the smart client (file->close) and start over?

Because it seems to me that it is the svn update that causes this, there are some new dbi files or server information files that suddenly have other columns or something

The first error is just a mbean register error that has nothing to do with this, but the second one (illegal state) is coming from the debug smart client, not the developer itself.
And it seems that the debug smart client does have the wrong kind of db information

3

jcompagner:
does this really also keep happening when you really restart the debug smart client?
So really close the solution in the smart client (file->close) and start over?

We are not using the File->Close option in the smart client because we hide all standard Servoy menu and toolbars, however we do close the debug smart client and then terminate all debug threads and then remove all terminated launches. That should count for “really closing the solution”, doesn’t it?

4

yes that is the same thing (File>close is just a quicker shortcut :) )

But after a restart of a debug client this really shouldn’t happen anymore, somehow the database structure the client works with doesn’t reflect real life.

5

jcompagner:
But after a restart of a debug client this really shouldn’t happen anymore, somehow the database structure the client works with doesn’t reflect real life.

Does the options “Enable/Disable Server” and “Reload tables/table structure form DB” interfere with that? Sometimes after updates from the SVN we need to use these options if another developer has made changes to the database schema and dbi files.

6

it could be the client gets its information from that location
But with a fresh start (close/open solution) it should then be in the latest refreshed state.