wtijsma wrote:
Otis wrote:
If you do generate the ddl sql update script, what exactly is altered in the script? That might be a hint where to check. Also, make sure you're using the latest build.
I've solved some of the issues by just setting all the "...Follows..." properties in the project to false.
If there are model elements which aren't in the DB, you have to, this is logical.
There's still strange issues though, I refreshed the SQL database where I added constraints which added all navigators, however refreshing DB2 after that removed them again. After refreshing SQL again they're not added again, and it keeps 'pending changes' active wanting to remove the constraints.
If 1 db doesn't have constraints while the other one does, you indeed run into this, this is unsolvable. However, you can simply toss away the create script or press the button to ignore the changes on the dialog which pops up (bottom option).
One of the other problems is that you can't refresh if there's validation errors (which as caused annoyance in other scenarios as well), but for example if you have a nullable column in DB 1 that's not nullable in DB 2, it will cause a validation error. However you can never refresh your schema anymore without completely deleting the property from the entity (and all related navigators), because you can never adapt it to a valid scenario.
If you map a model to 2 databases, they both should end up the same. If one DB can't be altered, you get differences between model and DB. So updating the schema in the project fixes this, but this requires you exporting a script. However the dialog which tells you to do so can be used to ignore it. All changes will then be ignored.
This isn't solvable, as the model has to be in sync with the schema. Otherwise the model can't be migrated to the new db schema after a refresh, simply because an invalid model can be anything.
Seems like the only thing that really works is keeping both schema's exactly the same, and make all the customizations model-only in LLBLGen Pro.
I do think not being able to map 'loosely' to a DB is a shortcoming though, because sometimes you have badly designed legacy databases and you can't change field lengths, column types etc but in your entity model you do want to be able to create relations between them.
You can map 'loosely' but only up to a point, as the model itself has to be valid and at some point the mappings too. You have two DBs where one doesn't follow the model at some point so you get a discrepancy which isn't solvable automatically.
It's impossible to simply have a model and map it to a totally different schema, as one follows from the other.