Hi! I'd like to know if there is a fast and simple solution for refactoring Layout/Table link.

I recently started to separated my data to the interface, so in that migration I have to refactor

all those fields in layouts (changing the data base - as it is now in another file/relation : got those <unlinked table>)

 

If you got clues go ahead I'm learning

 

Use mac and fmpro 11

 

tx

I have to refactor all those fields in layouts

All you should have to do is change the data source for the table occurrences already on the Relationships graph. Did you create new table occurrences pointing to the data file, maybe?  I don't understand why you should need to "refactor" fields on layouts.

Tx Dan

 

The thing is that it's an existing project with multiple tables, it's a "huge" project that a figure out should be redesign use the separation model as there will be update - and because a don't really want to touch the data - and because I just read about this modelling technic.

 

So, the project is there, and for the process of separation I did a copy and now I'm digging into isolating data from interface.

Now the drawback is that fields on the interface layout no longer point to their inner data file, they point now to external file (data) wish a linked trough the relational graph in the interface db.

 

Now all my field (in browser mode...) shows <unlinked table>. So I have to manually change their link and my problem is that I have too many fields

(and i'm not talking about script, triggers, calculation - I know I have a f... job to get there, but I have)

 

I just wonder if in fm pro (not advance) we can refactors all those fields link at ones.

 

Be reading your reply I tough - if I understand - I had just to create a TO of the data file into the interface file, but it seems that the fields just missed their link.

 

I hope it clears my problems, as one could really understand my topics

Tx

 

waiting for your advice.

 

 

I still think you are going about this the wrong way.  Have you read this post: http://fmforums.com/forum/topic/82917-creating-a-separation-model-from-an-existing-solution/

 

Is it possible to start the process of conversion to separation method over again?

Yes, in fact it all started there - my search on how-to actually design SM.

 

Your initial post was right!

What I did is creating a new TO instead of changing the source of an actual TO in the graph.

So now, the thing that I was missing was to change the layout/table link in manage layout - to point to that newly relinked TO (to db in the data file), and voila! 

 - all my fields gives me those data!

 

I don't know were I confuse you, but in a couple of sentence your initial post was correct.

The thing is that I know what is SM

 

Will have to dig for value list (in data)

Check for calculated fields issues that peoples are reporting

Put the related data script in data file, etc

Maybe I'll go for a script utility file - read in Jesse Feiller "Data-Driven IOS Apps for iPad and iPhone" to give me another layer of separation

Putting only the Layouts and UI scripts, triggers in the Interface file (going further up in dividing Desktop, form Mobile device)

 

If you have anything that could guide me, go ahead I'm learning curve!

 

Thanks a lot Dan!

 

 

Here is another website I like: http://filemakerstandards.org/display/props/Solution+development+models

Great! I'll check it out

 

Could you just guide with somethings I'm not quit sure of?

I came from fm 6, so jumping right trough 11 was a real big step, but am happy one: table concept, triggers, graphs, etc

 

But concerning my refactoring and working with the graph, knowing that I just made a copy of my db to slip it in data and interface

and the fact that I realize that I should remap my TO in the interface graph, one thing got trough my minds:

what about those "table" in the data file's graph.

 

A'm I a correct to say that the "real" relationship between tables are those from the data's file - with anchor and criteria

and the TO of the interface file should be left alone, without anchor and criteria; just a plain references (source to data file)?

 

Hope I'm not to esoteric?!

 

tx

A'm I a correct to say that the "real" relationship between tables are those from the data's file - with anchor and criteria

and the TO of the interface file should be left alone, without anchor and criteria; just a plain references (source to data file)?

No, I wouldn't call the TO's in your data file the "real" relationships. They are just TO's that the data file can use for calculated fields, value lists, etc. You can likely delete most of these TO's, as they were probably used for layouts and scripts more than for value lists and calculated fields.

 

I don't know what you mean by "anchor and criteria". If you want to access data stored in your data file from your interface file, you will need a TO that references the data file's table.

I don't know what you mean by "anchor and criteria".

 

 

By "anchor and criteria" I mean those lines with = or <=, I think it would be better to just say the relationship (between TO)

 

So the whole thing about establishing relationships between TO (especially those from the data file) takes place in the Interface file's graph.

I'll look forward for keeping TO in the data file for calculated fields, value lists soon or later.

 

Well, by now you really helped me out, thank you very much, sincerely and if your from the USA, Happy Thanksgiving day!

I'm sure I'll be needing your help one day or another, I'll know that I can find greet help here.

tx alot have a nice day.

 

 

ps. I just click on green and red arrow, by accident, didn't knew it stands for "reputation", *******!!!, your's is very high! tx

I'm glad I could help, good luck with your project.