Is it possible to use the generated classes within a SQL Assembly? I'm using version 3.0.

How are you planning to use the generated code? As .NET code inside SQL Server is meant for static functions or aggregates or types.

I would like to use the objects in the normal manner: to read data from and write data to the database the assembly reside in. The project type I'm referring to is "SQL CLR Database Project". I've done extensive work in these types of projects, using complex objects (non-generated) to accomplish a variety of tasks. These tasks are simply initiated by calls to SQL stored procedures and functions.

If possible, I assume that I will have to load some assemblies into the database in order to make this work. Any suggestions?

Doesn't using generated classes to interact with a database in an assembly which lives in and is called from the database itself seem kinda redundantly circular...

To be honest, I'm don't recall seeing anyone trying it before, so don't really have much to suggest. Give it a go and let us know how you get on ?

Matt

there are also problems with the requirement that all .net code has to be static and stateless inside SQLServer if I recall correctly. I couldn't find the specific threads on this forum where others have described their endeavors in this area (I do remember some tried).

Anyway, we haven't tested it for usage INSIDE sqlserver, nor do we consider it a use case for our code as it's not deliberately designed to be used inside sqlserver.

MTrinder wrote:

Doesn't using generated classes to interact with a database in an assembly which lives in and is called from the database itself seem kinda redundantly circular...

To be honest, I'm don't recall seeing anyone trying it before, so don't really have much to suggest. Give it a go and let us know how you get on ?

Matt

It's actually quite nice. Microsoft has made it so that any SQL Server access method that once would normally use works just fine. You simply use the connection string "Context Connection=true;" and that's all there is to it. Since it runs inside of SQL's (somewhat scaled down) CLR, the database access is that much quicker. It lets you write .NET code instead of a T-SQL stored proc or function.

Otis wrote:

there are also problems with the requirement that all .net code has to be static and stateless inside SQLServer if I recall correctly. I couldn't find the specific threads on this forum where others have described their endeavors in this area (I do remember some tried).

Anyway, we haven't tested it for usage INSIDE sqlserver, nor do we consider it a use case for our code as it's not deliberately designed to be used inside sqlserver.

The functions or stored procs must be declared static, but one can use actual instances of objects inside of these static stored procs and functions. It is possible to define and use classes inside of the SQL Assembly.

After doing some additional searching through the forums last night, I have read some other threads regarding this issue. From the discussions I read, it seems to me that it is unfortunately not possible to use the generated entities within a SQL Assembly. Perhaps in a future version?

I'm in the process of creating templates for a lightweight class of entities and collections that bypass LLBLGen Pro's data access, and therefore any need to reference the LLBLGen Pro assemblies. This is not an elegant solution by any measure, but it's much nicer than writing the classes by hand. I'm finding that the templates really provide a lot of flexibility now that I see how they work. I continue to be more and more impressed by your product.