This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I noticed that the visual designer adds the schema to the entity when you drop a table onto it. My production database and test database have two different schemas. Specifying the schema in the Test Context in the Config file apparently does not override the schema on the individual entities that were dragged over from the production database, because I kept getting "schema does not exist errors". Should it? Ideally, I would like to drop all the tables from the existing production database onto the visual designer and have then pick up enough about the tables so that I can: 1) Re-create the bare minimum in a test database by choosing update database... from the visual designer without having issues with identity generation, varchar(MAX), etc. See here: http://www.mindscape.co.nz/forums/Thread.aspx?ThreadID=1784 2) Not have to deal with schema issues by specifying a schema in a separate LightSpeed Context in config that I would think would override any schema settings the designer added when tables were dropped from a separate database with a different schema.
Honestly I could have solved all of this by easily running my redgate tools and just cloning the full database to my test server, but I am thinking the visual designer should provide more help in this matter. Note I could be doing something wrong, too, but I think it should be fairly simple to achieve this. Regards, Dave
|
|
|
That the per-entity Schema property overrides the default context schema is by design: that is its purpose, to make it possible to use tables from a schema other than the context default. (In terms of the underlying LightSpeed API, it maps to the TableAttribute). Therefore the problem is not that the entity schema is overriding the context schema, but that the designer is setting the entity schema when really you want it to be left blank (i.e. use the context schema). The designer sets the entity schema when the source table is in a schema other than the database default schema (e.g. dbo for SQL Server, the user for Oracle, etc.). Therefore if you are using SQL Server and the tables you drag onto the designer are in the dbo schema, you should be okay. However, given that you are dragging from the production database and therefore couldn't change the design even if you wanted to, this probably isn't much consolation! I'll look at adding an option to the designer to say "don't infer schema" or "default schema name" -- the former would be simpler but it may have to be the latter in order to support round-tripping -- anyway I will investigate and hopefully have something for you soon. |
|
|
Thanks, Ivan, but don't lose any sleep over this. 99% of the time I wouldn't expect to have the schema problem. I just happened to inherit it.
Regards,
Dave
|
|