We have been developing under 1.1 and SQL 2000 for a couple of years now and the powers that be have decided that we should begin the move to 2.0 and '05 now rather then later, business and cost reasons more then anything else.

They are expecting to make up the dev differential in productivity gains as well as new functionalities helping our product(s).

We are currently using LLBLGen to generate the DAL and so are a bit concerned about any plans to move to the new libraries and server and were hoping to get a feel as we will have to make a decision rather shortly about tools.

As I said, not moving is not an option..

Any input would be helpful ..

I have a feeling that our company will be soon moving to Yukon and .net 2.0. What are some good arguments against using .net objects in Yukon vs. LLBLgen? I've seen a little talk about this in the past. I remember Frans saying something to the tune that MS didn't leave Yukon open enough to allow LLBLgen based objects within the DB.

Does anyone see a potential for some headbutting between us devs (who want to use LLBLgen) and others who want to use Yukon integrated objects and .net coded SPs?

Sink wrote:

We have been developing under 1.1 and SQL 2000 for a couple of years now and the powers that be have decided that we should begin the move to 2.0 and '05 now rather then later, business and cost reasons more then anything else.

They are expecting to make up the dev differential in productivity gains as well as new functionalities helping our product(s).

We are currently using LLBLGen to generate the DAL and so are a bit concerned about any plans to move to the new libraries and server and were hoping to get a feel as we will have to make a decision rather shortly about tools.

As I said, not moving is not an option.. Any input would be helpful ..

The current LLBLGen Pro codebase (v1.0.200x.y) works ok on Yukon and .NET 2.0 beta 2. V2.0 of LLBLGen Pro (v2.0.200x.y) will get a re-worked framework solely targeted for .NET 2.0, based on generics, partial classes and other .NET 2.0 specifics. The same principles for querying etc. will be re-used though, to keep migration pains to a minimum.

The 1.0.200x.y codebase will be supported in v2.0 and will be updated to run without issues on .NET 2.0 and VS.NET 2005.

As .NET 2.0 offers generics, it's obvious some migration will be necessary if you want to move your code to .NET 2.0 specific code.

v2.0 of LLBLGen Pro is scheduled for the end of 2005, the current codebase will be supported on .NET 2.0 till then already, so you're not left in the cold. The current version generates .NET 2.0 projects already, so you can directly use them in vs.net 2005. Some bugs in vs.net 2005 beta 2 cause some issues with design time databinding in ASP.NET, these are fixed in teh final build of vs.net 2005.

lyndon_h wrote:

I have a feeling that our company will be soon moving to Yukon and .net 2.0. What are some good arguments against using .net objects in Yukon vs. LLBLgen? I've seen a little talk about this in the past. I remember Frans saying something to the tune that MS didn't leave Yukon open enough to allow LLBLgen based objects within the DB.

Does anyone see a potential for some headbutting between us devs (who want to use LLBLgen) and others who want to use Yukon integrated objects and .net coded SPs?

.NET objects in Yukon are pretty limited. They're ok, but in the maintenance area, you're in trouble. Say you define a column type on a .NET class. You need to update that class. You then first have to DROP the table, update the class assembly, and re-create the table.

.NET coded SP's... I'm not so sure. The problem is that SQL is a setbased language, it's far superior for working with sets than imperative languages like C#. SQL is slow for data processing though, so a mix can be best, though CRUD stuff is better off with SQL.

.NET procs are maintained in an assembly, maintaining them too has some problems, though less than the .NET types on tables. I've to test if one big .NET proc which calls into the generated code on the server is faster than code outside the server. The integration of .NET code with sqlserver isn't that high as I initially thought...

Otis wrote:

lyndon_h wrote:

I have a feeling that our company will be soon moving to Yukon and .net 2.0. What are some good arguments against using .net objects in Yukon vs. LLBLgen? I've seen a little talk about this in the past. I remember Frans saying something to the tune that MS didn't leave Yukon open enough to allow LLBLgen based objects within the DB.

Does anyone see a potential for some headbutting between us devs (who want to use LLBLgen) and others who want to use Yukon integrated objects and .net coded SPs?

.NET objects in Yukon are pretty limited. They're ok, but in the maintenance area, you're in trouble. Say you define a column type on a .NET class. You need to update that class. You then first have to DROP the table, update the class assembly, and re-create the table.

.NET coded SP's... I'm not so sure. The problem is that SQL is a setbased language, it's far superior for working with sets than imperative languages like C#. SQL is slow for data processing though, so a mix can be best, though CRUD stuff is better off with SQL.

.NET procs are maintained in an assembly, maintaining them too has some problems, though less than the .NET types on tables. I've to test if one big .NET proc which calls into the generated code on the server is faster than code outside the server. The integration of .NET code with sqlserver isn't that high as I initially thought...

Thanks for dropping that knowledge Frans. It always helps to have a lil ammo. Never know when you might need it.