datamining advice

[archlight]

Hi all,

I am new to filemaker. can anyone shine some light on the following situation?

currently I am trying to cross link among a few filemaker files. I have one luminare filemaker file and i have a lot of project filemaker files which have reference to luminaire list. now what I want to do is to has extra column to list all the projects this luminares has been used.

many thanks

[LaRetta]

Hi Archlight,

You would need to create a relationship (what you call a cross link) between your luminare file to each of your project files. But I must insert here first ... why so many project files? Ideally, you probably only want one project file with the project named or coded.

Your luminare file would have a ProductID. Your Project file(s) should have a ProductID (probably many products or lineitems) within each project. You relate luminare ProductID to project ProductID using the equal = sign. Then, two ways of accessing the information:

From luminare, viewing one product record at a time ... you place a portal of the project table on a luminare layout to view all projects (from the ONE project file) which are used by each product. But because you have MANY project files (or tables), you need many portals on the one luminare layout and would need to duplicate your efforts; truly it is best to combine the projects.

From Projects, create a report by luminare product ID ... you create a new layout, columnar with leading part. The leading part will be your luminare ProductID and product name. The body would hold project information. Then sort the report by luminare Product ID and go to Preview mode.

This is about all I can suggest since I don't know if your Projects have multiple products (indicating you should have another table for these lineitems); nor do I know whether you are using proper luminare ProductIDs or names. But this should get you moving a bit at least. Let us know how you're doing with it.

LaRetta

Edited October 15, 2008 by Guest
Added sentence

[archlight]

thanks for your reply.

what we implemented at moment is to maintain a single luminaire file where all individual project file link to it. originally we thought it is good to isolate but now it looks like one way street. is there a way to batch process a few files into a table indexed with product ID?

[LaRetta]

is there a way to batch process a few files into a table indexed with product ID?

Not enough information, I'm afraid. Do the Projects have any child records using their Project ID? I am unsure what you mean by 'indexed with product ID'. We would need to know your structure; actually, to see your files or ... if all the project files are identical, just one project file. But again, we cannot advise properly without seeing your situation.

In general ...

If your projects do NOT have children, then their ProjectIDs (you DO have ProjectIDs, right?) wouldn't matter. You would import all the files into one project file and let FileMaker reserialize them to a new ProjectID (use auto-enter serial increment). But I remain concerned by your lack of mention of a 'lineitems' table so you can have many luminare products within ONE project. If you have lineitems then the ProjectID MUST be maintained to link to the project's child records.

As for batch processing ... if only a few files, it wouldn't be worth it. If the field names are same, just import (after considering my above concerns). But you could import the first project file (and during import, specify in the target popup (down at the bottom of it) to create a new project table within your luminare [color:red]file). Then create script to import your remaining project tables into that one.

LaRetta

UPDATE: Changed the red from table to file

Edited October 17, 2008 by Guest

[LaRetta]

If you have lineitems then the ProjectID MUST be maintained to link to the project's child records.

Just to clarify further ... if you have child records (another table related to your projects) then you must maintain the ProjectID and assign a NEW ID to the projects (and its children) BEFORE migration to one project table. If reassignment of projects with children isn't handled properly, you could lose the kids; not good.