A lot of Clients with Solution <none>

[pbakker]

What happens when I update, it updates to 6. Or is there also a release of 5.2 available? Because a lot changed in 6...

I think that if you check out the Upgrade notes to Servoy 6.0, you'll notice that there isn't so much changed that causes you to make changes to your solution: http://wiki.servoy.com/display/DOCS/Upgrading+to+Servoy+6.0

Servoy 6 offers loads of new features and better Developer tools, but just getting your solution up and running in Servoy 6 should be very straight forward. Only when you want to reliably use some of the new features do you need to do some work adding JSDoc to get rid of warnings, but having those warnings doesn't mean you cannot use a lot of all the other new features.

Paul

[amcgilly]

I notice that early in this thread the poster reported getting this error:

Exception calling form method 'checkOnConnectionReset' with arguments null on form 'frmWebshop'in async mode on solution null

We recently ran into this kind of error message on code that was running as a scheduled job. It only came up on some job runs, not all, and we couldn't figure out what it meant. It was only when we ran the code 'manually' rather than as a scheduled job that Servoy accurately reported the error as a null pointer exception, and told us the offending line # in our code. It would be nice if Servoy had reported the bug like that even when the code was running as a scheduled job.

Is there something I should be doing differently so I get accurate error reporting in scheduled jobs? Is this something that I should log as a bug or enhancement request in the support system?

Thanks

[jcompagner]

that messages is not something that would cause a null pointer in your code (that i guess is being called)

I see "on solution null" so somehow the i guess scheduled method is being tried to executed but the solution is already closed.
Or that method did cause the solution to be closed. So that method did an application.exit()

Besides that if you see that message printed in your log, then you should also see the complete stacktrace being printed just above or below it..
That is what we do :

public void reportError(String msg, Object detail)
{
Debug.error(msg);
Debug.error(detail);
}

the msg == that message you have there
and the detail == the exception that really caused this.