I’m realize I’m behind the curve here, but I’m using 3.5.7 and really just getting started using Views (with Microsoft SQL Server 2005). My DBA is creating the views in SQL Server (or I am sometimes), and I am attaching forms to them. Then when I try to export the solution and import it at my home office, I’m encountering problems I’m sure are bugs. I am connected with dbo level permissions from Servoy to SQL Server, but I get one of several incorrect errors –
java.sql.SQLException: There is already an object named ‘viewprojectservoy2’ in the database. (Meaning it can’t create one, which I don’t want it to do anyway.)
or that I don’t have enough permission to modify that view (or one other).
or that it DOESN’T exist in the database (because I’ve just deleted it so that I could avoid the error above).
I’ve EVEN caught it creating ViewProjectServoy2 in the TABLES section of SQL Server, which I know is a bug.
Additional information: I got a copy of the MS SQL 2005 database exactly as it was when I exported my solution from Servoy, and it imported with that just fine. So this is less urgent, but I still think buggy?
Thanks Patrick. I know that tho – I had the views created before I started the import, it wouldnt work for the variety of errors above (not enough permissions to modify, claims that it didn’t exist, etc).
As Patrick said, Servoy does not create views, when it creates something it will be tables.
This kind of errors occur when the views are not reported by the database driver when Servoy asks for them but when a create (table) command is issued the database complains about the objects already existing.
Could it be that the catalog and/or schema points to a section of the db where the views cannot be found?
Yes it’s happening when I’m importing a Servoy solution that was attached to a view that does not exist in the backend at the import location. It’s adding them as a table – shouldn’t it just give me an error that there was no view where one was expected? Instead the import gives this error and creates the view as a table:
WARNING! The table 'viewprojectreporting in server ‘betawtd’ has type TABLE but in the import it has type VIEW. Servoy cannot keep the datamodels synchronized automatically if you use database views, please do so manually.
Here’'s this morning’s error moving from one repository to another: java.sql.SQLException: Cannot alter ‘ViewProjectServoy2’ because it is not a table.
Does this happen when you are importing a solution?
If you are using views, you will have to manage the views yourself, Servoy cannot see view definitions or create views in a database-independent way.
Yes on import. I don’t want Servoy to modify the views/manage them in any way. I just keep getting stuck on import (cannot import) because the views have been modified/differ between different installations of the database as I try to import the solution from one repository to another (home office to client’s office).
Servoy will only try to modify tables when there are columns in the database where the solution was exported from and those columns do not exist in the table or view in the target database.
So if you make sure all columns are there in the target database import should go fine, regardless whether it is a table or a view.
we have this problem also a lot with the NEM in Leiden
the views are created as tables, on the LIVE server, when the view is not there.
(views are created here by another person, and not by us, developers)
Is it possible, that Servoy stops the import, and make a notification, that we have to create the view first on the server?
During import a table is created instead of the view to keep the data model consistent. This issue is reported in the import log like: “WARNING! The table ‘test’ in server ‘test’ has type TABLE but in the import it has type VIEW. Servoy cannot keep the datamodels synchronized automatically if you use database views, please do so manually.” . You can delete those tables manually.
the LIVE DB server is not owned by us, but by an DB Administrator (other person)
So we would really like to first check if there are views, in our exportfile, than check if the view allready excist on the live server, if not, than STOP the import, so we can contact the DB Administrator first!!
In our support system a case (166499) is logged which will be implemented in Servoy 4.2, to prevent datamodel changes and first check if datamodel is oke, if not stop the solution import.
What Laurian explained are the current steps needed to deal with this upto Servoy 4.1.x