Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Designer> Table Change is not coming accross
 

Pages: 1
Designer
Table Change is not coming accross
Page:1/1 

  Print all messages in this thread  
Poster Message
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 12-May-2006 23:58:45.  
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
  Top
bclubb
User



Location:
Norman, Oklahoma
Joined on:
12-Feb-2004 22:18:04
Posted:
934 posts
# Posted on: 13-May-2006 03:24:49.  
Do you have AddNewFieldsAfterRefresh marked as true? This can be found under file->preferences and may cause some of the behavior you are encountering.

  Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 15:19:25.  
AddNewFieldsAfterRefresh is set to true.

  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14639 posts
# Posted on: 15-May-2006 15:29:45.  
From the LLBLGen Pro manual:

Quote:
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?


  Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 15:48:18.  
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.
  Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 15:54:45.  
I just compared the preference of the new project that's working that the project that's not and they are identical.

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 15-May-2006 16:06:40.  
Please state database type, database system version, provider used (e.g. odp.net 10g, 9i etc.) and llblgen pro designer build date (about box).
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 16:15:02.  
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



  Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 16:17:16.  
The project was originally created from a SQL 2000 db, could that be the problem?
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 15-May-2006 16:51:11.  
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?



Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 15-May-2006 17:05:15.  
It's not part of a hierarchy.
The fields do not show up in the unmapped fields tab.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 15-May-2006 17:54:18.  
Ok I'll see if I can reproduce it.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 16-May-2006 11:24:13.  
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
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TogasPoon
User



Location:
Minneapolis, MN USA
Joined on:
09-Feb-2006 17:11:07
Posted:
42 posts
# Posted on: 16-May-2006 22:24:57.  
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.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 16-May-2006 23:03:58.  
Sorry you had to spend the time to recreate the project... Embarassed

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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
mikeg22
User



Location:

Joined on:
30-Jun-2005 20:09:32
Posted:
411 posts
# Posted on: 02-Aug-2007 19:59:57.  
Otis wrote:
Sorry you had to spend the time to recreate the project... Embarrassed

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.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 02-Aug-2007 23:29:32.  
Answered via email.

(view's metadata doesn't contain field nullability, so they're set to false for nullability)
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
arschr
User



Location:
Atlanta, Georgia; USA
Joined on:
14-Dec-2003 16:57:29
Posted:
892 posts
# Posted on: 04-Aug-2007 14:43:49.  
Quote:
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?


- Al  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 04-Aug-2007 18:18:29.  
arschr wrote:
Quote:
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.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
arschr
User



Location:
Atlanta, Georgia; USA
Joined on:
14-Dec-2003 16:57:29
Posted:
892 posts
# Posted on: 04-Aug-2007 20:08:43.  
Quote:
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.


- Al  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
38092 posts
# Posted on: 06-Aug-2007 12:58:14.  
arschr wrote:
Quote:
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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.