I changed two fields to not allow nulls and when I refresh the catalogs the fields still show up as allowing null. If I look at the fields in the Catalog Explorer the fields don't have anything under Is Nullable (vs. showing True before) so the change is reflected there.

I've also tried adding fields to the table to see if they would show up and they don't. They do, however, show up in the catalog explorer.

Is there a setting somewhere that I'm missing?

Also, I tried creating a new project and adding this table to see what would happen. Any changes I make there are coming across correctly.

I could drop the entity and then recreate it but that would be a lot of extra work and still wouldn't fix my problem if I need to make changes in the future.

I'm using 1.0.2005.1 Final but I get the same results with the new v2 beta.

Thanks

Do you have AddNewFieldsAfterRefresh marked as true? This can be found under file->preferences and may cause some of the behavior you are encountering.

AddNewFieldsAfterRefresh is set to true.

From the LLBLGen Pro manual:

AddNewFieldsAfterRefresh When set to true (default), any newly found, unmapped field in an entity's target, which aren't removed previously from the entity, is added as a new entity field to the Entity automatically after a catalog refresh has been completed, except if the entity is in a TargetPerEntityHierarchy hierarchy and not the root of the hierarchy. If the entity is in a TargetPerEntityHierarchy hierarchy and the new target field is not nullable, it's added to the root entity only, if this setting is set to true.

Also do you see the changes in the Report shown after the refresh?

The changes are not displayed in the report.

Added fields to the table are not appearing either, unless I add a new entity based on that table, then they show up properly.

I just compared the preference of the new project that's working that the project that's not and they are identical.

Please state database type, database system version, provider used (e.g. odp.net 10g, 9i etc.) and llblgen pro designer build date (about box).

MS SQL Server 2005 SqlClient

I've tried with the new v2 beta (2.0.0.0 beta - May 9th, 2006) and 1.0.2005.1 Final - March 31st 2006

[edit] Added build dates

The project was originally created from a SQL 2000 db, could that be the problem?

No that shouldn't be a problem. The entity, is it in a hierarchy? (e.g.: is there a hierarchy of type TargetPerEntityHierarchy mapped on the table?) Do the fields show up in the 'unmapped fields' tab in the entity editor?

It's not part of a hierarchy. The fields do not show up in the unmapped fields tab.

Ok I'll see if I can reproduce it.

I can't reproduce the not-logging of the change.

I've done: - create a new project on a database, add the entities. Save, exit. - changed 2 fields in 1 table from nullable to non-nullable. - started llblgen pro again, loaded the project, did a catalog refresh: Entity 'Orders' IsNullable flag of field 'EmployeeId' changed to 'False'. IsNullable flag of field 'CustomerId' changed to 'False'. Entity migrated.

When I then check 'Orders' in the entity editor, indeed these two fields have 'Is nullable' 'false'.

I then added 2 new fields to Orders in the database. Did again a refresh of the catalog: Entity 'Orders' Entity migrated. field 'TestField2' added at position '15'. field 'TestField1' added at position '14'.

The fields are indeed added to the entity.

My pref settings: AddNewElementsAfterRefresh: true AddNewFieldAfterRefresh: true

I'm not able to reproduce it either.

I finally broke down and recreated my project from scratch. Everything is working on my new project and any changes I make to the DB are reflected after a refresh. I've compared preferences and properties and if something is different I'm not seeing it.

I'm chalking it up to one of those things and moving on. Thanks for the effort.

Sorry you had to spend the time to recreate the project...

Either way, if you run into it again, please keep the project file and the schema and send it to me so I can try to reproduce it here.

Otis wrote:

Sorry you had to spend the time to recreate the project...

Either way, if you run into it again, please keep the project file and the schema and send it to me so I can try to reproduce it here.

I have this problem also. I will send my project file to you now.

Answered via email.

(view's metadata doesn't contain field nullability, so they're set to false for nullability)

view's metadata doesn't contain field nullability, so they're set to false for nullability

If the nullability is unknowable, wouldn't true be a "better" default?

arschr wrote:

view's metadata doesn't contain field nullability, so they're set to false for nullability

If the nullability is unknowable, wouldn't true be a "better" default?

I don't think so, as a not-nullable field which is under the hood perhaps a nullable field doesn't cause runtime errors but a nullable field which is under the hood a non-nullable field will cause problems at runtime.

I don't think so, as a not-nullable field which is under the hood perhaps a nullable field doesn't cause runtime errors but a nullable field which is under the hood a non-nullable field will cause problems at runtime.

I guess I look at it from the other side of the river. A nullable field in the view that coresponds to a not nullable field in the table will cause an exception when you try to save it. A not-nullable field on the view, that is nullable in the table will never be able to have a null placed in it. The developer, may think that s/he needs to add code to the ui to prevent nulls, rather than go to the "source" and have them update the nullability in the designer.

It's probably no win either way, but the idea of nullability is a way of saying I don't know, and in this case the designer doesn't know what the nullability should be.

arschr wrote:

I don't think so, as a not-nullable field which is under the hood perhaps a nullable field doesn't cause runtime errors but a nullable field which is under the hood a non-nullable field will cause problems at runtime.

I guess I look at it from the other side of the river. A nullable field in the view that coresponds to a not nullable field in the table will cause an exception when you try to save it. A not-nullable field on the view, that is nullable in the table will never be able to have a null placed in it. The developer, may think that s/he needs to add code to the ui to prevent nulls, rather than go to the "source" and have them update the nullability in the designer.

It's probably no win either way, but the idea of nullability is a way of saying I don't know, and in this case the designer doesn't know what the nullability should be.

IMHO, Nullability of a field means: the field can be undefined. It's not a signal that the person who defined the field wasn't sure if the field is nullable or not.

If you want to make a field nullable, you can check the Is nullable checkbox in the entity designer of the entity mapped onto the field.