Is Nullable Not Available in Designer

Posts   
 
    
jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 04-Oct-2007 17:03:53   

Environment: 1. LLBLGen Pro 2.0 (July 6, 2007 build) 2. Oracle ODP.Net 10

Issue: All of the entities that I'm adding have 100% of non-key fields set to Is Nullable = true with Is Nullable grayed out and unchangeable in the designer.

How can I get the ability to set Is Nullable?

I've attached a screenshot showing all of the options greyed out for a column. Is Nullable (and the .Net 2.0 nullable type option) is the primary option I'd like to be able to set by column.

Thanks, Jason

Attachments
Filename File size Added on Approval
IsNullableNotAvailable.png 20,281 04-Oct-2007 17:04.12 Approved
jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 04-Oct-2007 20:32:11   

Also note, the schema is full of check constraints preventing null values. I don't need LLBLGen to reflect this automatically, but I do need to be able to set it up correctly in the designer so the compiled code can enforce these constraints.

What's happening, if I pass a NULL to a field with a check constraint, is that I get an Oracle error referring to the check constraint (almost all check constraints are system named (C000353652 for example) so the error is meaningless to anyone but a developer/DBA).

This is happening on all entities in the schema (30 tables or so).

I figure it's not a database provider issue, I can't see any reason the designer would limit this type of functionality on that basis.

I've also reviewed Preferences and project Settings, nothing seems related to the issue.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39613
Joined: 17-Aug-2003
# Posted on: 04-Oct-2007 20:45:39   

Are these entities mapped to views or to tables? Because if they're mapped to views, this is always the case.

If they're tables, I'll see if I can reproduce it. (What's the ODP.NET version btw?) (my test project in v2.5, using ODP.NET 10.2 works correctly, it has fields nullable and some not nullable)

Frans Bouma | Lead developer LLBLGen Pro
jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 04-Oct-2007 21:00:38   

All tables (I unchecked Views and Stored Procs when loading the schema). All tables are in the login schema (many tables are visible via synonyms and show up in the designer, I'm only including those that are in the login schema in this situation).

Oracle.DataAccess DLL Version (Assembly Version in Properties from Windows Explorer): 10.1.0.400 Runtime version (from VS.Net IDE): v1.0.3705

Let me know if you need further information. I will try this out with the MS provider and see if I get different results.

Thanks, Jason

jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 04-Oct-2007 21:26:16   

I have tried the following scenarios, all leading to the same situation: 1. LLBL 2.0, ODP 10 (per version in previous post) 2. LLBL 2.0, MS Oracle 3. LLBL 2.5, MS Oracle

All result in 100% "enforced" nullable fields (enforced = can't change in the designer). The only un-nullable fields are the primary key fields (which the designer is identifying as such).

I do get the "some tables don't have primary keys" warning after loading the schema, but all tables that I'm adding have primary keys (and are related to one another).

The table list presented by the designer includes lots of tables outside of my schema (it names them as if they are in my schema), but I'm only selecting tables in the schema (synonyms).

In all cases I unchecked the Stored Procs and Views options when loading the schema.

It doesn't seem to matter which version or provider I aim at this schema, the result is always the same.

I'm taking off from work now, but I will do further testing tomorrow with different schema/database combinations.

If you would like I could attach project files, let me know.

Thanks, Jason

jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 04-Oct-2007 21:37:58   

All right, we did a refactoring (didn't recreate tables, just dropped indexes, constraints, and triggers, altered tables, and then recreated everything) recently.

Comparing the before and after tables in Toad (great Oracle developer tool) the old table reflects the proper nullable fields. The refactored table shows all fields as nullable (check constraints actually enforce the non-nullability of the correct fields, but the table def appears to have changed even though we only ran an alter table on one field per table).

Now, pointing LLBLGen at the old table it correctly reflects the null/no null, but it's still greyed out and not changeable.

Anyway, just more information. I guess I mostly wondering why I can't "override" the database settings, especially in terms of forcing values to not be null.

Walaa avatar
Walaa
Support Team
Posts: 14950
Joined: 21-Aug-2005
# Posted on: 05-Oct-2007 11:29:00   

Now, pointing LLBLGen at the old table it correctly reflects the null/no null, but it's still greyed out and not changeable.

Anyway, just more information. I guess I mostly wondering why I can't "override" the database settings, especially in terms of forcing values to not be null

As far as I know, you can't change the Is Null property in the designer. It should reflect that of the database.

So you have the following options: 1- Correctly have a database schema that reflects your reqirements. 2- If you don't want to change your database schema, use a dummy schema to create the LLBLGen project against it which should correctly contain the Not Nullable settings. 3- Use LLBLGen validation framework, to entities before save to not include null values.

jturpin
User
Posts: 20
Joined: 30-May-2007
# Posted on: 05-Oct-2007 14:03:02   

Thanks for the suggestions and the info regarding how Is Nullable works in the designer. I'm looking at altering the tables to restore the not null portions of the table definition.

This appears to be a lesson regarding Oracle, removing all check constraints alters the tables, removing all non-null constraints. The table appears altered although the only SQL statements executed were "drop constraint ...".

From there alter table statements were ran, but only to change the data type of key columns (from varchar2 to number, want to integrate fully with LLBLGens sequence integration feature).

Restoring the constraints (100% identical, including name) enforces all of the previous constraints (including all non-null fields), but it leaves the tables altered.

I'm going to look at restoring the table level constraints, because the check constraints are not reflected by LLBLGen (nor would I expect them to be, that would be pretty tight coupling to a particular database).

Thanks, Jason