Hello Knut, We have spent considerable effort in testing migration of large applications, with the help of several customers. In these migration runs, we have not seen this problem. Nonetheless, we're keen to understand and resolve this issue.  For thorough analysis it's more convenient to handle this outside of this thread. Once we know what's going on, we'll report back in this forum. Henk van der Veer

Hi Knut (and Henk), in Uniface 10, relationships are maintained as part of the Many Entity and no longer as part of the One Entity (Uniface 9). Are you aware of that change? Maybe you are looking for your relationships in the wrong entities. The reason why we did this is because foreign keys, used in a relationship, are defined in the many entity, so if you need to change your relationship you probably need to change foreign key definitions and therefore the many entity. In Uniface 10, that would only change a single source being the Many Entity. Gerton

Hi Henk, Thank you for taking the time to speak with me on the phone - and using Goto Meeting. I agree, the information is actually there - albeit in a illogical way (at least in my mind). To the rest of the Unifacer's out there, my mind is still grappeling with the neccessity to change from a one-to-many concept for defining relationships, to the new many-to-one relationship and the thinking behind it.... Ask any dba, enterprise architect, data modelling person to draw out a customer, order_header, order_line, part_master relationship - and you'll get a one-to-many diagram. I have yet to see a white-board drawing of a data model, started from the bottom of the white-board. Hopefully, hopefully, we can get a way of representing the concept of one-to-many in a non-graphical way, and be able to define relationships in a 'normal' manner, as in one-to-many rather having to find the many, and define the relationship to the one... Knut

Gerton, Not sure I agree here. If I need to change a relationship, I would sever it at the one level - because I know I don't need the link anymore. If I picked the wrong field as the FK - I'm still very capable of linking on the new, correct field from the parent. It is not logical to have to search through 15 children to find where they belong - I should be able to go to the parent and find all the children. Anyways, it is what it is - hopefully there's some scope to revert to a 'normal' way of thinking...

I see both points.  When I am building a model, I'll build the one entity, then build the many entity then create the relationship, which would have required me to change entities (sometimes even models) to get to the parent and then set up the relationship to the child I was just editing.  However, when changing the parent later, it is probable that I'd like to know easily what other entities depended on it (the many entities.) In at least a display format.  Frankly, the information should be available from either side of the relationship....  Iain

Very rarely these days do I find a complete 'green-field' environment where I have to completely start from scratch and define all my entities from scratch. I'd 'slurp-and-burp' an existing DDL catalogue - having all tables, fields and keys imported directly into my repository. For this reason alone, it would make sense to start at the highest level and work down. I'd have as a guess that most new customers of Uniface would be in this position - even from a pre-sales perspective that you'd 'slurp-and-burp' a model. And yes, Iain's last statement - the information should be available from both sides. Knut

I thing that Knut is right, you always defines the relation from the master to the slave. So why is Uniface doing the opposite? To make it harder for finding new developers who already know SQL Server and Oracle for defining relations...   We are waiting with the migration to Uniface 10, I think at least until 10.4 exists. We migrated to U9.7 when it was released and we have had many troubles after...

SQL Server works from the Many to the one. I've just tried their foreign key deisgner, and you start using the design function from the many entity (slave?) and change the Primary Key entity in the designer.  The TSQL command is a create or alter table command on the many/child/slave entity not the one/master/parent.  Generally, as I said above, when I'm creating new tables, I'm either creating the heirachy from the top down (Define the One table, define the many table, create the relationship), so the last table I am changing is the many table, and therefore getting to the relationship from there is best, or I'm adding a new UP entity, create the table, go to the existing many table, add the relevant foreign key fields, create the relationship. Again, I'm in the child when I want to create a relationship.  However, I need to be able to see all the relating tables from either direction to remind me what's going on, so there should be visibility of the many relationships from the one table. 

One way that you can see the one-to-many relationships from the one entity is to use the graphical navigator in the Resource Browser. In the Define Relationship worksheet: Select an entity in the list view of the Resource Browser and double-click it. This will display the entity as a block in the center of the diagram, and its relationships, supertypes, and subtypes (if applicable). You can click any of the entities that it is related to to navigate to them. A One entity will show all its 'slave' Many entities. --- Barbara

Just a small question: I think we still have the mechanism that we need all the many entity markers to activate integrity control in a component. So there is some need to see it from the "one" side, as we could specify for frame-in-frame rename. Well we can use GOLD-W and create a nice little SQL query to get all "MANY"-infos for a given "ONE" entity-model pair. But perhaps providing the good old metadictionary and the ADDITIONAL menu to start a form inside the IDF would give us the option for this report without putting all that implementation burdon on the sholders of the U10 development team. Uli

The GOLD-W way (use $IDF as data path): SELECT U_RGLAB, U_RVLAB FROM ucrelsh where U_GLAB = "A1ONE" and U_VLAB = "ACIF1"

As sqlite string concatenation operator is ||, a better select may be: SELECT U_GLAB || "." || U_VLAB as ONE, U_RGLAB || "." || U_RVLAB as MANY FROM ucrelsh where U_GLAB = “A1ONE” and U_VLAB = “ACIF1” It would be nice if we could use the printf() function where a documented example looks like:

But this is only available with SQLite 3.8.3 or greater (Feb 2014 release) As select sqlite_version() will tell, uniface SQLITE driver id on some 3.7 version only Well, it's time for weekend, best wishes to all of you, Uli

Uli, Well, yes, we could do that - but that goes against the grain of the new IDE being 'user-friendly' to a newbie. Old hacks like myself can (and indeed do these things) - but as Adrian stated in Vegas two weeks ago, he'd like / love to get to the point where hacks like myself don't need to get to the repository... Long live 'power to the hacks!'. Knut

Knut said ... he'd like / love to get to the point where hacks like myself don't need to get to the repository ...

Hi Knut, think we all can still remember the times when the uniface product came with a lot of useful reporitory reports somewhere in the mid 90s. But times have changed, just have a look what we get nowadays as repository viewers.