I am struggling with several "Specified cast is not valid" errors with a (embedded) Firebird database. For example one occurs on a field which is a FLOAT in the database and is specified as FbDbType.Double to System.Double in the mappings in PersistenceInfoProvider.vb in the generated DBSpecific code. Strangly however, another field (though in another entity) of the same type and specs works just fine ... LLBLGen version = 2.5 October 25th 2007

Is it a compile exception or a compile error? Could you please post the exception stack trace (if applicable). Also pleast post your relevant code snnipet where you are getting the exception.

could you please try to refresh catalog and then regenerate to a new empty folder?

daelmo wrote:

Is it a compile exception or a compile error? Could you please post the exception stack trace (if applicable). Also pleast post your relevant code snnipet where you are getting the exception.

could you please try to refresh catalog and then regenerate to a new empty folder?

It's an exception; I've added the details as an attachment. This is where I get the exception: Private Function OmschrijvingOpToets(ByVal eKey As PosTouchKeysEntity) As String Return (eKey.KortOmschr & IIf(eKey.Record.Value > 0, vbCrLf & "# " & eKey.Record.ToString, "")) End Function

I shall try to explain my DAL configuration / workflow in a nutshell: * I have one dbgeneric DAL which is generated from a sql server database catalog. * I have four different dbspecific DAL's for sqlserver, access, mysql and firebird. * I have one BL (build with JCL templates) based on the DAL's mentioned above. * I only refresh the catalog in the base project (the sqlserver one that is). * The projects for the other databasetypes will be build from the base project via LLBLGEN's ProjectConverter. Then the whole bunch is regenerated with LLBLGEN's CliGenerator and recompiled with Visual Studio. In this way I can have one application (executable) which supports 4 different databasetypes. So far works fine for sqlserver, access and mysql.

The issue must be something related with the project converter, while I'll look into it you could opt to generate your DAL directly from your Firebird catalog as workarround.

You get a cast error when the property 'Record' is read in the PosTouchKeys entity. What's the .net type and the db type of that field? And in the debugger: what's the field value of Record in that PosTouchKeys entity instance? (check in .Fields[index].CurrentValue )

Otis wrote:

You get a cast error when the property 'Record' is read in the PosTouchKeys entity. What's the .net type and the db type of that field? And in the debugger: what's the field value of Record in that PosTouchKeys entity instance? (check in .Fields[index].CurrentValue )

ekey.Fields("Record").DataType = System.Double firebird db type = FLOAT ekey.Fields("Record").CurrentValue = 4.0 {Single}

Code line from PersistenceInfoProvider.vb from the firebird dbspecific project: MyBase.AddElementFieldMapping( "PosTouchKeysEntity", "Record", "Record", True, CInt(FbDbType.Double), 8, 0, 0, False, "", Nothing, GetType(System.Double), 4 )

goose wrote:

you could opt to generate your DAL directly from your Firebird catalog as workarround.

Did the above suggestion work for you?

Walaa wrote:

goose wrote:

you could opt to generate your DAL directly from your Firebird catalog as workarround.

Did the above suggestion work for you?

No If I do refresh the catalog from the firebird database, almost all typed lists and relation mappings ,which were converted from my (sqlserver) base project, are removed. I was able though to regenerate the firebird dbspecific project, resulting in the following code in PersistenceInfoProviderCore.vb: MyBase.AddElementFieldMapping( "PosTouchKeysEntity", "Record", "Record", True, CInt(FbDbType.Float), 4, 0, 0, False, "", Nothing, GetType(System.Single), 4 ) Which differs from the one I described earlier (FbDbType.Double => System.Double).

software123 wrote:

Walaa wrote:

goose wrote:

you could opt to generate your DAL directly from your Firebird catalog as workarround.

Did the above suggestion work for you?

No If I do refresh the catalog from the firebird database, almost all typed lists and relation mappings ,which were converted from my (sqlserver) base project, are removed. I was able though to regenerate the firebird dbspecific project, resulting in the following code in PersistenceInfoProviderCore.vb: MyBase.AddElementFieldMapping( "PosTouchKeysEntity", "Record", "Record", True, CInt(FbDbType.Float), 4, 0, 0, False, "", Nothing, GetType(System.Single), 4 ) Which differs from the one I described earlier (FbDbType.Double => System.Double).

If that's the case, all relations are removed, which means that the FK constraints aren't available in your firebird database. Is that the case?

Anyway, you have to make SURE the firebird database has the tables,pk's etc. as the project thinks it has. So the best way is to generate DDL from the converted project and use that as the db. If you have a firebird db already, the firebird db has to have the fk constraints between the tables.

Otis wrote:

software123 wrote:

Walaa wrote:

goose wrote:

you could opt to generate your DAL directly from your Firebird catalog as workarround.

Did the above suggestion work for you?

No If I do refresh the catalog from the firebird database, almost all typed lists and relation mappings ,which were converted from my (sqlserver) base project, are removed. I was able though to regenerate the firebird dbspecific project, resulting in the following code in PersistenceInfoProviderCore.vb: MyBase.AddElementFieldMapping( "PosTouchKeysEntity", "Record", "Record", True, CInt(FbDbType.Float), 4, 0, 0, False, "", Nothing, GetType(System.Single), 4 ) Which differs from the one I described earlier (FbDbType.Double => System.Double).

If that's the case, all relations are removed, which means that the FK constraints aren't available in your firebird database. Is that the case?

Anyway, you have to make SURE the firebird database has the tables,pk's etc. as the project thinks it has. So the best way is to generate DDL from the converted project and use that as the db. If you have a firebird db already, the firebird db has to have the fk constraints between the tables.

With ProjectConverter I created subprojects for access, mysql and firebird from my base project (sqlserver). The base project is the one in which the actual designing happens (refresh catalog, typed lists, etc). Relations are created in the sqlserver database. No (physical) relations within the other databases (only PK's and triggers/generators). These databases are converted from the sqlserver one. Works fine for sqlserver and access, mysql works except for character "-" containing fieldnames (see other thread) and firebird works except for (some?) float fields. The idea was to have (to manage) only one BL project, one dbgeneric DAL project and four different dbspecific DAL projects for one application so I can switch easily from dbtype without having to recompile my application or having four different versions. I hope I 've made my point clear ...

I understand, but that's not always going to work, as not all databases support the same types. The more databases you want to support, the more you run the risk that you have to use a typeconverter here and there to make the types match.

Although you want to keep just 1 db for designing, it will likely be a bit of a problem in the end, unless you use just a small subset of the sqlserver types, namely the ones which are available in all databases you support and which also have the same .net type.

The converter can't always make the right decision based on the information it has. Therefore it's often better to do: - convert project to target db into new lgp - generate DDL SQL using template - check DDL SQL generated and update it to match what you want - create schema in db from DDL SQL - refresh the new lgp file onto the schema created.

From there, you probably will have to maintain 2 or more database schemas as it's unavoidable that you will run into type mismatches here and there, or sillyness like the '-' characters in names, or other things, like max length of a name, max length of a field which isn't possible on db 1 but is possible on db 2 etc.

Otis wrote:

I understand, but that's not always going to work, as not all databases support the same types. The more databases you want to support, the more you run the risk that you have to use a typeconverter here and there to make the types match.

Although you want to keep just 1 db for designing, it will likely be a bit of a problem in the end, unless you use just a small subset of the sqlserver types, namely the ones which are available in all databases you support and which also have the same .net type.

The converter can't always make the right decision based on the information it has. Therefore it's often better to do: - convert project to target db into new lgp - generate DDL SQL using template - check DDL SQL generated and update it to match what you want - create schema in db from DDL SQL - refresh the new lgp file onto the schema created.

From there, you probably will have to maintain 2 or more database schemas as it's unavoidable that you will run into type mismatches here and there, or sillyness like the '-' characters in names, or other things, like max length of a name, max length of a field which isn't possible on db 1 but is possible on db 2 etc.

All probs solved now. * Firebird; I had to create two typeconverters, one for FbDbType.Double from/to System.Double (for all FB fields of type FLOAT) and one for FbDbType.SmallInt from/to System.Byte (for one specific field, which should have been a "tinyint", which is not supported in FB and was converted to FB type INTEGER during database conversion from sqlserver to FB) * MySql; There was an error in the MySql DQE dll; I received a new version from you, which solved the problem.