We are using MS SQL Server user defined data types. When reading the schema only native data types are shown. We would like to have access to information (the name) for the user defined data type. To accomplish this, we can create type converters for all our user defined data types and then at runtime check which type converter is assigned to the field. Unfortunally this means, that we have to create type converters for each field type even though the only purpose is to get access to the name of the user defined data type. The information is needed for the automatic setup of input fields. It is of course possible to do the setup without the name of the user defined data type but it is much easier for us this way. Is there any other way to get information about the user defined data type?

Further more, in out database, we have the same native data type mapped to more than one user defined data type. With the filter available when defining type conversion definitions in the LLBLGen Pro designer there’s no way to tell, that a specific type converter only should be used with fields with a specific user defined data type. Is there any other solution than assigning type converters to each field manually?

Regards, Nikolaj Halvorsen

Nikolaj wrote:

We are using MS SQL Server user defined data types. When reading the schema only native data types are shown. We would like to have access to information (the name) for the user defined data type. To accomplish this, we can create type converters for all our user defined data types and then at runtime check which type converter is assigned to the field. Unfortunally this means, that we have to create type converters for each field type even though the only purpose is to get access to the name of the user defined data type. The information is needed for the automatic setup of input fields. It is of course possible to do the setup without the name of the user defined data type but it is much easier for us this way. Is there any other way to get information about the user defined data type?

Could you explain to me why you would need a type converter in this situation? A user defined type in sqlserver which isn't a CLR type (sqlserver 2005) is simply a redefine of a sqlserver type, e.g. varchar. A typeconverter is used to map a different .net type onto a db type.

The information is available in the table fields meta data in the project. Though it's not used by the llblgen pro designer.

If you're using UDT's which are CLR types, you will have the field types be equal to the CLR types, IF the llblgen pro designer can load the CLR type assembly, e.g. from the GAC.

Further more, in out database, we have the same native data type mapped to more than one user defined data type. With the filter available when defining type conversion definitions in the LLBLGen Pro designer there’s no way to tell, that a specific type converter only should be used with fields with a specific user defined data type. Is there any other solution than assigning type converters to each field manually?

You can set a typeconverter automatically on a type-precision-length-scale combination (or combi without any of the elements mentiond), however I still don't see why you would need a typeconverter which simply converts a .NET type to a db type to overcome the absense of such a mapping.

Otis wrote:

Nikolaj wrote:

We are using MS SQL Server user defined data types. When reading the schema only native data types are shown. We would like to have access to information (the name) for the user defined data type. To accomplish this, we can create type converters for all our user defined data types and then at runtime check which type converter is assigned to the field. Unfortunally this means, that we have to create type converters for each field type even though the only purpose is to get access to the name of the user defined data type. The information is needed for the automatic setup of input fields. It is of course possible to do the setup without the name of the user defined data type but it is much easier for us this way. Is there any other way to get information about the user defined data type?

Could you explain to me why you would need a type converter in this situation? A user defined type in sqlserver which isn't a CLR type (sqlserver 2005) is simply a redefine of a sqlserver type, e.g. varchar. A typeconverter is used to map a different .net type onto a db type.

The information is available in the table fields meta data in the project. Though it's not used by the llblgen pro designer.

If you're using UDT's which are CLR types, you will have the field types be equal to the CLR types, IF the llblgen pro designer can load the CLR type assembly, e.g. from the GAC.

Further more, in out database, we have the same native data type mapped to more than one user defined data type. With the filter available when defining type conversion definitions in the LLBLGen Pro designer there’s no way to tell, that a specific type converter only should be used with fields with a specific user defined data type. Is there any other solution than assigning type converters to each field manually?

You can set a typeconverter automatically on a type-precision-length-scale combination (or combi without any of the elements mentiond), however I still don't see why you would need a typeconverter which simply converts a .NET type to a db type to overcome the absense of such a mapping.

The problem is, that the same native type is mapped to more UDT's (without any difference in type-precision-length-scale). An example could be the UDT's Date and Time mapped to the DATETIME type. We're unable to distingush between these types without knowing the UDT (or a specific type converter) and automatic setup of an edit mask would be impossible. Another example could be the UDT's Initials and Password both mapped to a VARCHAR(10).

The use of type converters makes it possible for us to either create global validation for properties or just enforcing valid values for these without writing the same code for every entity using a specific UDT.

Being able to filter on the name of the UDT in the designer when mapping type converters would be enough.

Though that has nothing to do with typeconverters, or I must be missing something . The thing is that typeconverters are used to convert from a given .net type to a given db type.

So you then should convert the db types to different .net types, and based on that .net type you should run different code but isn't that a bit odd? Or am I missing a detail?

I think you're looking for generating code based on the UDT name, am I correct?

Otis wrote:

Though that has nothing to do with typeconverters, or I must be missing something . The thing is that typeconverters are used to convert from a given .net type to a given db type.

So you then should convert the db types to different .net types, and based on that .net type you should run different code but isn't that a bit odd? Or am I missing a detail?

I think you're looking for generating code based on the UDT name, am I correct?

I wan't two things:

1) To be able to see the what UDT af specific property is mapped to. I can use the type converters to accomplish this even though it is a bit odd but it was the only solution I could come up with. Unfortunally I can't map the UDT to a type converter automaticly in the designer, because I can't filter on the UDT name. The .NET type could be af custom class and in this case the type converter actually serves it purposes and at the same time gives me the needed information about the UDT (the type converter).

2) Global validation and enforcing valid values for properties mapped to UDT's. I don't think this is very odd even though I'm only able to throw exceptions when validating.

If code generation means acces to the UDT name for a property the answer is yes. This will give me the possible to create a simple entity validator, that can validate/enforce valid values for all UDT properties.

Nikolaj wrote:

Otis wrote:

Though that has nothing to do with typeconverters, or I must be missing something . The thing is that typeconverters are used to convert from a given .net type to a given db type.

So you then should convert the db types to different .net types, and based on that .net type you should run different code but isn't that a bit odd? Or am I missing a detail?

I think you're looking for generating code based on the UDT name, am I correct?

I wan't two things:

1) To be able to see the what UDT af specific property is mapped to. I can use the type converters to accomplish this even though it is a bit odd but it was the only solution I could come up with. Unfortunally I can't map the UDT to a type converter automaticly in the designer, because I can't filter on the UDT name. The .NET type could be af custom class and in this case the type converter actually serves it purposes and at the same time gives me the needed information about the UDT (the type converter).

2) Global validation and enforcing valid values for properties mapped to UDT's. I don't think this is very odd even though I'm only able to throw exceptions when validating.

If code generation means acces to the UDT name for a property the answer is yes. This will give me the possible to create a simple entity validator, that can validate/enforce valid values for all UDT properties.

The UDT information is in the table/view field's TypeDefinition property.

I think you're helped with a modified customproperty plugin which adds a custom property to the fields which contains the UDT name. This is then accessable by a template so you can generate code based on that custom property.

If you open the plugin 'Project inspector' by rightclicking the project node in project explorer -> run plugin, you can browse to an entity, its fields, the mappedfield object which contains a TypeDefinition property which contains an object which has UserDefinedType information (catalog, schema owner, name). This is accessable by a plugin in the designer. Please check out the SDK for the sourcecode of the plugins so you can easily modify the customproperty plugin to traverse the entities and add custom properties to the fields which have a type mapped onto a UDT.

I'll look into that - thanks.