The Designer generate code with Precision = 0 in the EDMX when a Precision is undefined in a table definition in PostgresSQL 8.4.1. The generated project will not compile since the Precision is set to 0. Devart Designer generate the same code but omit the Precision attribute in the case it was undefined in the table definition for a Numeric data type.

NUMERIC without any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision. A column of this kind will not coerce input values to any particular scale, whereas numeric columns with a declared scale will coerce input values to that scale. (The SQL standard requires a default scale of 0, i.e., coercion to integer precision. We find this a bit useless. If you're concerned about portability, always specify the precision and scale explicitly.)

Thanks,

Charlie J.

What version and builddate (date in titlebar) of the designer are you using? Because the template already omits precision in the SSDL when it's 0. (precision isn't emitted in the CSDL part). Make sure you're using the latest build.

Otis. I and using LLBLGEN 3.1 (Build June 17, 2011). Yes you are right. It is omitted in the SSDL part, but the problem is with it included in the CSDL part. The generated project will not compiled with the Precision set to 0. I have to go delete the attribute from the CSDL to get it to compile.

Thanks,

Charlie J.

Ah found it. I overlooked it this morning. It indeed always emits Precision when it's 0.

I changed the general utils templates which emits these types, to omit the Precision attribute when it's not > 0. I couldn't find any info whether having no precision but having a scale attribute would be bad (both are optional according to the docs). Still I think npgsql should accept precision == 0 as 'undefined', but alas.. can't have everything.

Copy the attached template as administrator into: <llblgen pro installation folder>\Frameworks\Entity Framework\Templates\Shared\Shared

Thanks Otis. I will try the patch and let you know.

Thanks,

Charlie J.

Thanks. That patch worked like a champ. I did run into a problem with a timestamptz field in the my Postgres Database. I will open a new message thread on this one.

Thanks,

Charlie J.

Hey Otis,

Did this patch made it in the last release dated July 1, 2011 or I still have to apply the attached patch?

The change log shows that the fix went into the 06292011 build, so should be included in the latest version. Are you not seeing the fix in there...?

Matt

Yes. The Precision fix is in the latest build. I tested it and it works.

Thanks,

Charlie J.