Why do I keep getting a failed import in Servoy 5.2 on the application server/admin web page with the error:
There is already a style with the name ContactMgmt
when I have “Overwrite repository styles with import version” checked? I’ve imported this solution (with styles) at least six other times in 5.2 release candidates – no problem. I’ve tried this import five times in the last few minutes – it names a different of my four styles each time, but fails each time. I’m allowing database changes, I’ve tried clean import and not, I’ve tried merge and don’t. Nothing works.
Restarted the service, and this time it deleted the styles before it tried to import. But then…
[error] Error in transaction
…which I think I always get when I try to import with users… So I did it without users, and it worked. Something up with importing with users to server?
ellenmeserow:
Restarted the service, and this time it deleted the styles before it tried to import. But then…
[error] Error in transaction
…which I think I always get when I try to import with users… So I did it without users, and it worked. Something up with importing with users to server?
Can you post the full error(s) from log file ? (servoy_log.txt)
Today’s log is attached – I tried to import with users again. I will import now without users, the same .servoy file, and it will work.
UPDATE: It didn’t work. It had half of the solution loaded I guess, got a repository error. Restarted the service, all is well again. Import without users fine.
ellenmeserow:
Today’s log is attached – I tried to import with users again. I will import now without users, the same .servoy file, and it will work.
UPDATE: It didn’t work. It had half of the solution loaded I guess, got a repository error. Restarted the service, all is well again. Import without users fine.
This is indeed a bug in 5.2.0 final. It doesn’t work to import the user information in repository at solution import(so application server import). Will be fixed in 5.2.1 .
I’m not sure there’s anything you can do about this, but I thought I would mention it… in case one day something occurs to you all. If import fails for some reason, the service really has to be restarted. Since I’m in the process of training someone at my client to import solutions for me into production, I live in fear of that day. It rarely happens, but all of the above that I mentioned will do it, as I said. Today I broke the service by accidentally hitting my keyboard ‘esc’ key while I was importing. It behaved nicely, reporting that the import was stopped, but the server never really returns to normal. CLEARLY my problem, but I thought I’d ask if there’s anything you can do to make it less sensitive. This was my test server, so only my testers were inconvenienced while I task manage ended all of their client sessions and restarted the service… but when this happens to my trainee on production, I’m gonna get the panic call as 50 users at multiple sites all start calling her. Just asking. Thanks!
ellenmeserow:
I’m not sure there’s anything you can do about this, but I thought I would mention it… in case one day something occurs to you all. If import fails for some reason, the service really has to be restarted. Since I’m in the process of training someone at my client to import solutions for me into production, I live in fear of that day. It rarely happens, but all of the above that I mentioned will do it, as I said. Today I broke the service by accidentally hitting my keyboard ‘esc’ key while I was importing. It behaved nicely, reporting that the import was stopped, but the server never really returns to normal. CLEARLY my problem, but I thought I’d ask if there’s anything you can do to make it less sensitive. This was my test server, so only my testers were inconvenienced while I task manage ended all of their client sessions and restarted the service… but when this happens to my trainee on production, I’m gonna get the panic call as 50 users at multiple sites all start calling her. Just asking. Thanks!
You can open a case in our support system with some scenario(s) which trouble you and we’ll have a look at how to improve.
I just reproduced the style sheet exists bug that this thread is about. First, I got the below error on import of my solution with allow changes to database model/database turned on (and reporting of those changes). The version does include a new table called ‘versions’ created in another instance of servoy developer (offsite) then imported into Servoy Developer at my client (onsite), exported from that Servoy developer and imported into application server (with team repo turned off). Both Developer and Application Server are connected to the same MS SQL Server 2005 databases (most of which are not mine to control, but this ‘versions’ table is mine).
Importing PRISM_2010_08_16_1045.servoy...
[info] Import contains XML version 15 and repository version 38.
[warning] Reserved words used as table or column names: columns: other;
[info] Deleting existing Style 'KCWTDURS2'.
[info] Deleting existing Style 'KCWTDURS'.
[info] Deleting existing Style 'Reporting'.
[info] Deleting existing Style 'ContactMgmt'.
[warning] The server version of the column 'reportid' of table 'params' in server 'user_data' allows NULL values while the import version does not.
[info] Created table 'versions' in server 'user_data'.
[info] Added column with name 'version_id' to table 'versions' in server 'user_data'.
[info] Added column with name 'version_desc' to table 'versions' in server 'user_data'.
[info] Added column with name 'change_desc' to table 'versions' in server 'user_data'.
[info] Added column with name 'bugs_desc' to table 'versions' in server 'user_data'.
[info] Added column with name 'dev_date' to table 'versions' in server 'user_data'.
[info] Added column with name 'deploy_date' to table 'versions' in server 'user_data'.
[info] Added column with name 'deploy_name' to table 'versions' in server 'user_data'.
[info] Added column with name 'developer' to table 'versions' in server 'user_data'.
[error] java.sql.SQLException: There is already an object named 'versions' in the database.
Then since it seems to have created my table, I tried importing again the same solution with database model changes allowed UNCHECKED to get around whatever made it confused that it created the versions table (presumably on import to developer) and got this WITH overwrite styles checked:
Importing PRISM_2010_08_16_1045.servoy...
[info] Import contains XML version 15 and repository version 38.
[warning] Reserved words used as table or column names: columns: other;
[warning] The server version of the column 'automanual_id' of table 'automanual' in server 'user_data' allows NULL values while the import version does not.
[warning] The server version of the column 'reportid' of table 'params' in server 'user_data' allows NULL values while the import version does not.
[warning] The server version of the column 'qtr_nbr' of table 'viewcontractpcoreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'year_id' of table 'viewcontractpcoreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'rpttitle_id' of table 'viewcontractpcoreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'rptseq_id' of table 'viewcontractpcoreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'budget_id' of table 'viewcontractmilestones' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'proj_id' of table 'viewprojectreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'rpttitle_id' of table 'viewprojectreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'year_id' of table 'viewprojectreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'qtr_nbr' of table 'viewprojectreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'col_id' of table 'viewprojectreport' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'tier1_id' of table 'viewtierwithadjust' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'tier2_id' of table 'viewtierwithadjust' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'userid' of table 'viewuseremail' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'datetype_id' of table 'viewprojphasedate' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'section_id' of table 'viewraterscore' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'wtdunit_id' of table 'viewwtdsectionunit' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'rpttitle_id' of table 'tblproj20rpt' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'proj_id' of table 'tblproj20rpt' in server 'data' allows NULL values while the import version does not.
[warning] The server version of the column 'cm_id' of table 'cm' in server 'data' allows NULL values while the import version does not.
[error] There is already a style with the name KCWTDURS
As with all my previous problems with import to application server in 5.2, restart of the service solves this completely and the very same solution imports fine. There’s clearly something wonky about the import process, unless I’m doing this all wrong as i am still new to the separation of developer and server coming from 3.5.12. If not, I’m hoping will be smoother in 5.2.1. Restarting the service in production mid-day is not going to go over well here.