Hello,

We have some nchar columns that accept strings from who knows where, so someone was kind enough to program a little neat function that checked GenPro's field length property

field.MaxLength

and if the given string .Length property was longer than that, it substringed the original string

fieldValue.Substring(0, field.MaxLength);

It worked wonders targeting SqlServer, the problem now is that we're targeting Oracle (using ODP.NET 9.2.0.7). So my field is NCHAR(25) but field.MaxLength equals 50

Help! Is this something I can work around in a reasonable fashion?

Thanks for your time, álvaro.-

Alvaro wrote:

Hello,

We have some nchar columns that accept strings from who knows where, so someone was kind enough to program a little neat function that checked GenPro's field length property

field.MaxLength

and if the given string .Length property was longer than that, it substringed the original string

fieldValue.Substring(0, field.MaxLength);

It worked wonders targeting SqlServer, the problem now is that we're targeting Oracle (using ODP.NET 9.2.0.7). So my field is NCHAR(25) but field.MaxLength equals 50

Help! Is this something I can work around in a reasonable fashion?

Thanks for your time, álvaro.-

álvaro,

The MaxLength property value is initially set to the length of the database column this field is mapped on. I find it strange that the property returns an erroneous result in Oracle if the schema hasn't changed.

1) Please verify your schema 2) Did you regenerate your DAL for Oracle? 3) Which LLBLGen Pro version are you running?

Are you refreshing the catalog on an 8i system?

I just re-checked the .lgp and oracle schema.

The .lgp consistently reports all nchar fields as having twice their oracle schema length. In particular, the field that gave me problems is nchar(25) and the .lgp says its length is 50.

The database is 9i but I think it's got its compatibility mode set to 8i, could that be the problem?

Oh, my LLBLGenPro version is 1.0.2004.2 final (August 5th 2005), the installer came out on october 10th.

Thanks! álvaro.-

Alvaro wrote:

I just re-checked the .lgp and oracle schema.

The .lgp consistently reports all nchar fields as having twice their oracle schema length. In particular, the field that gave me problems is nchar(25) and the .lgp says its length is 50.

The database is 9i but I think it's got its compatibility mode set to 8i, could that be the problem?

Oh, my LLBLGenPro version is 1.0.2004.2 final (August 5th 2005), the installer came out on october 10th.

There's a problem determing the info correctly on 8i, as it misses a vital meta-data field. Could you please execute the following query using toad on the 9i box: SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH, DATA_PRECISION, DATA_SCALE, NULLABLE, DATA_DEFAULT FROM ALL_TAB_COLUMNS WHERE OWNER=:schema AND TABLE_NAME = :tableName ORDER BY TABLE_NAME ASC, COLUMN_ID ASC

and replace :schema with the schema name in quotes, like: 'SCOTT' and :tableName with the name of the table with the nchar field, like 'EMP'.

The value in DATA_LENGTH is the value that's stored in Length in the field.

In 1.0.2005.1, I've added a check for 9i so it could use the field CHAR_LENGTH which isn't available on 8i.

If you append , CHAR_LENGTH to the select list, you'll see '25' instead of '50', which is the data_length.

As it's a rare case and we're not updating 1.0.2004.2 anymore other than emergency bugfixes, I can mail you the sourcecode for the 1.0.2004.2 drivers so you can add the few lines of code from the 1.0.2005.1 driver's OracleSchemaRetriever.cs file of the OracleDBDriver to the 1.0.2004.2 code.

It's recommended though you upgrade to 1.0.2005.1.

Well... just like you said:

SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH, CHAR_LENGTH, DATA_PRECISION, DATA_SCALE, NULLABLE, DATA_DEFAULT FROM ALL_TAB_COLUMNS WHERE OWNER='GPIREZ' AND TABLE_NAME = 'AConfirmedTransaction' ORDER BY TABLE_NAME ASC, COLUMN_ID ASC

One of the troublesome columns:

COLUMN_NAME = MerchantName DATA_TYPE = NCHAR DATA_LENGTH = 50 CHAR_LENGTH = 25 DATA_PRECISION = DATA_SCALE = NULLABLE = Y DATA_DEFAULT =

Correct me if I got this wrong, but since the database is actually 9i and it has the CHAR_LENGTH column, then it's some sort of "if oracle version is 9i" on your schema reading code, which evaluates to false because of the compatibility mode?

Because, errrm, I just re-checked with our DBA and he had got me wrong the first time

SELECT name, value, description FROM v$parameter
         WHERE name = 'compatible'; 

returns 9.2.0.1.0

So what could be causing this?

By the way, I couldn't be more eager to upgrade to 1.0.2005.1, however it's just not possible right now.

Well as usual thanks for your support. cheers álvaro.-

Alvaro wrote:

Well... just like you said:

SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH, CHAR_LENGTH, DATA_PRECISION, DATA_SCALE, NULLABLE, DATA_DEFAULT FROM ALL_TAB_COLUMNS WHERE OWNER='GPIREZ' AND TABLE_NAME = 'AConfirmedTransaction' ORDER BY TABLE_NAME ASC, COLUMN_ID ASC

One of the troublesome columns:

COLUMN_NAME = MerchantName DATA_TYPE = NCHAR DATA_LENGTH = 50 CHAR_LENGTH = 25 DATA_PRECISION = DATA_SCALE = NULLABLE = Y DATA_DEFAULT =

Correct me if I got this wrong, but since the database is actually 9i and it has the CHAR_LENGTH column, then it's some sort of "if oracle version is 9i" on your schema reading code, which evaluates to false because of the compatibility mode?

No, the code isn't present in the 1.0.2004.2 driver code. The check and support code was added in 1.0.2005.1.

Because, errrm, I just re-checked with our DBA and he had got me wrong the first time

SELECT name, value, description FROM v$parameter
         WHERE name = 'compatible'; 

returns 9.2.0.1.0

True, though the 1.0.2004.2 driver doesn't check for this.

I've checked with windiff and the differences between the two drivers is not big, so you could do the following: - download the SDK - in the SDK, there's the sourcecode for 1.0.2005.1 drivers. It's best to copy the OracleDBDriver project to a separate folder and open it separately, so no other projects are loaded. - In the OracleDbDriver project, change the references to the SD.LLBLGen.Pro.DBDriverCore assembly of the 1.0.2004.2 designer. (it's now referencing the 1.0.2005.1 version). - Open AssemblyInfo.cs, and change 1.0.2005.1 into 1.0.2004.2, and remove the reference at the bottom to the strong key.

Open OracleDBDriver.cs. Remove the aspect addition at line 109, as that's not defined in 1.0.2004.2. (you'll get a compile error).

The code now should compile. This driver also enables XmlType support, if you need that in 1.0.2004.2, you also have to add support code for that to the DQE.

After the code compiled, make a backup copy of the current dll in LLBLGenProInstallationFolder\Drivers\Oracle and replace it with the just compiled dll. Then restart the designer and refresh the catalog.

Well thank you very much for your support. This does seem like a lot of work for this particular problem though...

If I get to do it (before upgrading to 1.0.2005.1) I will let you know how it goes.

cheers álvaro.-