Hi all,

We just started using LLBLGen Pro and we're scratching our heads over how to use it most effectively in our development environment.

We have a development database which is where developers go to create/tweak/play with tables and records during development. We have a "live" production database that hosts the real data on production machines. Development usually has everything that Production has, but not vice versa.

Should we use a single LLBLGen project file and "point it" to Development as we're building, and then to Production after we've migrated the DB changes and are ready to deploy? Should maintain both Development and Production LLBLGen project files?

If it's more than one project file, it seems like it would be a burden to keep both files synchronized without some sort of selective import feature. If it's only one, then we risk breaking the DAL when the databases are out of synch. (They're out of synch a lot because we use dev to tweak DB structure until it's just right.)

Any thoughts? Is there a best practice for this?

Thanks in advance for your input!!

-Alex

Use the dev database as the source for your project file. After all, the code written works with that database. If production is way different, the code will break anyway.

It's also a matter of what follows what. In general the following scenario is followed: - in the beginning there is no production db, just dev db(s) - the dev db is used to build the software. In the end, when the software is said to be 'releasable', the database reaches its final state - the production database is setup like the dev db is, as the dev db is the database layout the software can work with.

when features have to be added: - there is a production database, v1.0 - the dev db is modified, to make the new functionality possible. Every CHANGE is logged and written in SQL DDL migration scripts. These are important, as they've to be used to MIGRATE the production database to the new version. Migration is a tedious, important task, as it might take millions of records to be migrated so this should be done with care. - the developers use the dev db to write hte new functionality. - the db change scripts are now first tested in a test environment so the migration can be tested, tweaked etc. - when the migration scripts are finalized, the production database is migrated to the new layout - the new software is then deployed.

Rule of thumb: the production database is off limits. It's production, you don't develop on production databases, they're the result of work which is finalized.

Good point. If the data tier doesn't work when we deploy because of differences int he database, then we probably have bigger problems to work through.

Thanks for your speedy and complete response!

-Alex

Good point. If the data tier doesn't work when we deploy because of differences int he database, then we probably have bigger problems to work through.

Is there anyway to verify the code generated from the dev database will work against production DB - at least from an interface viewpoint? For example, are all the tables, views and procedures (with parameters) called by LLBLGen actually implemented in the production DB?

Has anyone written a tool that compares the generated code to the schema of the live database?

It would be nice to know of these problems before a user finds them at runtime...

Thanks

Phil

PLethbridge wrote:

Has anyone written a tool that compares the generated code to the schema of the live database?

It would be nice to know of these problems before a user finds them at runtime...

I wrote some additions to the Manager templates to generate a nunit project which does exactly this. It generates a set of NUnit tests which executes read / write tests against a database for all generated Entities and uses a COM+ transaction to cleanup afterwards.

You can find the template's described at http://llblgen.com/tinyforum/Messages.aspx?ThreadID=1892 and the source is in the related subversion source tree.

Marcus

Marcus, I didn't even know that was in the manager templates, cool stuff!

PLethbridge wrote:

Good point. If the data tier doesn't work when we deploy because of differences int he database, then we probably have bigger problems to work through.

Is there anyway to verify the code generated from the dev database will work against production DB - at least from an interface viewpoint? For example, are all the tables, views and procedures (with parameters) called by LLBLGen actually implemented in the production DB?

Has anyone written a tool that compares the generated code to the schema of the live database?

It would be nice to know of these problems before a user finds them at runtime...

Thanks

Phil

I would recommend that you take a look at SQL Compare from Red Gate. It is a great application. It basically highlights differences in structure and data of 2 databases, and allows you to reconcile the differences.