Skip to main content

Query on - Code Build and Deployment from Lower (lets say (Development) to higher (Test) environment

Author: jayesh.g.patel@accenture.com (Jayesh82mscit)

In the recent time, we had been facing issue with the compilation of Uniface components when entity related changes (Uniface Model Changes) moved from Development environment to Test environment. While we are following monthly release process, we do have Dev to Test movement once in a month with whole code base of developed code. Recently we had made major entity changes (in which we introduced 20+ different columns within 4-5 tables) and started facing the sporadic errors in Test environment related -35 on different screens post the deployment. If developer try next time, error gets disappeared. Only common factor while investigating, we noticed the one of the changed tables (part of Model changes) is painted in the service component from where error is originated. As a solution (though it was not confirmed one), we rebuild all the table changes from scratch in development environment and rebuild them and deployed into TEST. But this time along with /all switch we also used the /con switch within build process. Good part is this has resolved the sporadic -35 error. Until the last test deployment, we never used the /con switch but only using /all. But from the last deployment to Test, we would like to understand if /con switch would have played any role resolving the sporadic error ? Should we remove the /con switch from our build process or should we keep /con switch in our build process ? Any suggestion would greatly appreciated. Application - Web based application Back end DB - DB2/400  

Query on - Code Build and Deployment from Lower (lets say (Development) to higher (Test) environment

Author: jayesh.g.patel@accenture.com (Jayesh82mscit)

In the recent time, we had been facing issue with the compilation of Uniface components when entity related changes (Uniface Model Changes) moved from Development environment to Test environment. While we are following monthly release process, we do have Dev to Test movement once in a month with whole code base of developed code. Recently we had made major entity changes (in which we introduced 20+ different columns within 4-5 tables) and started facing the sporadic errors in Test environment related -35 on different screens post the deployment. If developer try next time, error gets disappeared. Only common factor while investigating, we noticed the one of the changed tables (part of Model changes) is painted in the service component from where error is originated. As a solution (though it was not confirmed one), we rebuild all the table changes from scratch in development environment and rebuild them and deployed into TEST. But this time along with /all switch we also used the /con switch within build process. Good part is this has resolved the sporadic -35 error. Until the last test deployment, we never used the /con switch but only using /all. But from the last deployment to Test, we would like to understand if /con switch would have played any role resolving the sporadic error ? Should we remove the /con switch from our build process or should we keep /con switch in our build process ? Any suggestion would greatly appreciated. Application - Web based application Back end DB - DB2/400  

Hi Jayesh We don't use /con but analyse the model "by hand" on a regular base  i.e. after changes to the model, short before any deployment. Why? 'cause Uniface will use the ULANA to build the SQL-scripts for creating a table. BTW: -35 is not an error generated by Uniface on it's own, but as a follow up after you return in some trigger a negativ status: -35   UGENERR_4GL_SAYS_ERROR     "A trigger returned a negative value in $status. " So you have to check, what was before the status=-35 Ingo


Author: istiller (i2stiller@gmx.de)

Query on - Code Build and Deployment from Lower (lets say (Development) to higher (Test) environment

Author: jayesh.g.patel@accenture.com (Jayesh82mscit)

In the recent time, we had been facing issue with the compilation of Uniface components when entity related changes (Uniface Model Changes) moved from Development environment to Test environment. While we are following monthly release process, we do have Dev to Test movement once in a month with whole code base of developed code. Recently we had made major entity changes (in which we introduced 20+ different columns within 4-5 tables) and started facing the sporadic errors in Test environment related -35 on different screens post the deployment. If developer try next time, error gets disappeared. Only common factor while investigating, we noticed the one of the changed tables (part of Model changes) is painted in the service component from where error is originated. As a solution (though it was not confirmed one), we rebuild all the table changes from scratch in development environment and rebuild them and deployed into TEST. But this time along with /all switch we also used the /con switch within build process. Good part is this has resolved the sporadic -35 error. Until the last test deployment, we never used the /con switch but only using /all. But from the last deployment to Test, we would like to understand if /con switch would have played any role resolving the sporadic error ? Should we remove the /con switch from our build process or should we keep /con switch in our build process ? Any suggestion would greatly appreciated. Application - Web based application Back end DB - DB2/400  

Hi Jayesh, you need to analyze the Uniface model every time you make changes to your entities. It will create or update the entity descriptors. If you are scripting your deployment process, you need to use the /con switch. If you check the documentation for /all, you can see that it does NOT include the /con switch, so you must run it separately.  Do /con before /all because the compilation of components performed in /all will read the entity descriptors created with /con. I recommend you keep the /con switch in your build process . Stefan


Author: StefanH-US (stefan.hirsch@uniface.com)

Query on - Code Build and Deployment from Lower (lets say (Development) to higher (Test) environment

Author: jayesh.g.patel@accenture.com (Jayesh82mscit)

In the recent time, we had been facing issue with the compilation of Uniface components when entity related changes (Uniface Model Changes) moved from Development environment to Test environment. While we are following monthly release process, we do have Dev to Test movement once in a month with whole code base of developed code. Recently we had made major entity changes (in which we introduced 20+ different columns within 4-5 tables) and started facing the sporadic errors in Test environment related -35 on different screens post the deployment. If developer try next time, error gets disappeared. Only common factor while investigating, we noticed the one of the changed tables (part of Model changes) is painted in the service component from where error is originated. As a solution (though it was not confirmed one), we rebuild all the table changes from scratch in development environment and rebuild them and deployed into TEST. But this time along with /all switch we also used the /con switch within build process. Good part is this has resolved the sporadic -35 error. Until the last test deployment, we never used the /con switch but only using /all. But from the last deployment to Test, we would like to understand if /con switch would have played any role resolving the sporadic error ? Should we remove the /con switch from our build process or should we keep /con switch in our build process ? Any suggestion would greatly appreciated. Application - Web based application Back end DB - DB2/400  

Hi Jayesh, I'd say "it depends" - it depends on if you're using any of the entity services concepts (the checkbox in the entity definition screen (3 tier generation / business object)). If you're using the 'traditional' components created with io directly from that said component - I personally don't see any reason to do a /con. Except of course, if you need to create a table - but from what I read, your system is an existing system with existing tables. Regards, Knut


Author: Knut (knut.dybendahl@gmail.com)
Terms & ConditionsAccessibility statement