I'm using the newest 2.0 version. In the help file under section "Generated code - Using the entity collection classes, Adapter" is this:

For .NET 2.0, you should use this declaration to define a generic EntityCollection instance:

// C# .NET 2.0 EntityCollection<CustomerEntity> customers = new EntityCollectionEntityCollection<CustomerEntity>(new CustomerEntityFactory());

Note that "EntityCollectionEntityCollection" is a typo.

My question is around what the proper pattern should be for declaring/using EntityCollections now. In this example, a typed EntityCollection is used (as opposed to IEntityCollection or IEntityCollection2). Would you ever declare the instance as the interface type, or should the interface types only be used as method/parameter types for passing the collections around? Or does it matter either way?

Also, I assume that we should only be using IEntityCollection2 for any new code?

Thanks, Brian

bmoeskau wrote:

I'm using the newest 2.0 version. In the help file under section "Generated code - Using the entity collection classes, Adapter" is this:

For .NET 2.0, you should use this declaration to define a generic EntityCollection instance:

// C# .NET 2.0 EntityCollection<CustomerEntity> customers = new EntityCollectionEntityCollection<CustomerEntity>(new CustomerEntityFactory());

Note that "EntityCollectionEntityCollection" is a typo.

Thanks, will fix that.

My question is around what the proper pattern should be for declaring/using EntityCollections now. In this example, a typed EntityCollection is used (as opposed to IEntityCollection or IEntityCollection2). Would you ever declare the instance as the interface type, or should the interface types only be used as method/parameter types for passing the collections around? Or does it matter either way?

Also, I assume that we should only be using IEntityCollection2 for any new code?

In general it doesn't matter: both give access to the entity collection's features. However, the interface can be convenient if you have to work with an EntityCollection<T> and you don't know what T is, which can happen. Then you could use the interface.

Use the generic class if you want a strongly typed collection. Use the EntityCollection class (which is non-generic) if you don't need a strongly typed collection and want to return it from a webservice for example.

Cool, thanks.

We've got our existing site converted over to LLBL 2.0 (along with converting to VS 2005 and SQL 2005, all at the same time ). We've got everything up and running with several nice new table inheritance hierarchies, and so far we are loving the new stuff! Thanks for all the hard work

Brian

How did the SQL2005 conversion go? Any issues? I have not gone down that road yet, but guess I will have to before too long.

bmoeskau wrote:

Cool, thanks.

We've got our existing site converted over to LLBL 2.0 (along with converting to VS 2005 and SQL 2005, all at the same time ). We've got everything up and running with several nice new table inheritance hierarchies, and so far we are loving the new stuff! Thanks for all the hard work Brian

@wayne: you shouldn't run into any issues, as SqlServer 2005 is backwards compatible with 2000, only if you do meta-data reading it might be a struggle, but that's a given. With llblgen pro, just set the DQE in 2005 mode (see manual) and you're good to go

My concerns are mostly around the schema owner changes and ownership chaining changes.

I think both changes are for the better in SQL2005, but maybe some issues there - and I was speaking more from a database question.

You mean, schema Foo doesn't have to be owned by user Foo, but can be owned by user Bar? That's indeed a change, but IMHO it shouldn't affect much code I think. After all, the DML/DDL simply refers to a schema, who owns it is not that much of a problem, UNLESS your DDL scripts assume that an object is created in a given schema because you logged in as a given user

What if procs and other code do not specifically state 'dbo' as the owner - if I only have one schema - will still work good?

The ownership chaining should be better in the new release, but it will definately not work in a straight conversion as it is now - but should not be hard to address. I may look at it this winter...

WayneBrantley wrote:

What if procs and other code do not specifically state 'dbo' as the owner - if I only have one schema - will still work good?

If you're logged in as the dbo user or as an admin, it should indeed be added to the default schema, dbo.