Super Portal! Need help

[tripdragon]

I found out how to dp basic relationship stuff. Took awhile but it workks.

Now I need to be able to pull databases from a million different database files. into the portal and or a basic non portal relationship file.

Think of it like a master database for all and every recond alive. Is that possible ?

When I tried it with the portal it will olny see the data from one file as far as I can see it.

I have the demo of FM7 Will that help any ? I know that the biggest new feature is the use of more than one tab;e but I am not sure what good that will do.

FileMaker Version: 6

Platform: Mac OS X Panther

[Reed]

if you create a constant calculation field in both the main file and the related file, and then created a relationship based on that constant, the portal using that relationship would show every record in the related file.

If you actually have 1 million separate files from which you want to pull data, you might want to consider consolidating some of the files....

even if you have a million records in your portal, you probably want to filter that portal somehow so you don't have to spend your whole day scrolling

[stanley]

TripDragon:

Each portal can show data from only one relationship, so what you might end up with is a master layout with a number of portals on it... If you really just want to be able to see ALL the data in your solution, you could put a constant field in every database, as Reed suggested, then base relationships on those constants for every db in your solution. Then you can make as many portals as you want, and they'll show all of your records...

-Stanley

[tripdragon]

Reed said:

if you create a constant calculation field in both the main file and the related file, and then created a relationship based on that constant, the portal using that relationship would show every record in the related file.

If you actually have 1 million separate files from which you want to pull data, you might want to consider consolidating some of the files....

even if you have a million records in your portal, you probably want to filter that portal somehow so you don't have to spend your whole day scrolling

Well okay I fibbed a bit It is more like 500 Is that not enough ?

Now ... If I may ask ... Could I get a quick tutorial on how to add this calculation ? I know how to add fields and other things but this one is new to me. I would be ever so greatful for the help.

[Reed]

If you actually have 500 different .fp5 files, are they all tracking different things with unrelated information? If not, you could logically arrange the data so similar types of data can go into the same file. Give me an example of the data stored in the different files.

If you really want to show data from that many different files you will have to create 500 separate relationships and 500 separate portals. This is not a task that sounds like much fun.

Dana

[tripdragon]

Reed said:

If you actually have 500 different .fp5 files, are they all tracking different things with unrelated information? If not, you could logically arrange the data so similar types of data can go into the same file. Give me an example of the data stored in the different files.

If you really want to show data from that many different files you will have to create 500 separate relationships and 500 separate portals. This is not a task that sounds like much fun.

Dana

Lord no it is not to much fun!

Think of it like this. These are tapes. And each tape has to have it's own file to keep it clean and far from the others but they all still need to be readable inside of a MASTER database. They all have the same data arangement to theme as a template.

Now the portal sounded like a proper clean method. But that only works with one file.

So yes I need it to have a relaltionship with each one.

I am in hopes that I do not need to create a million plus relationships. In PHP it would just all sit in a file and the script would tag each and every file and pull all of it's data without any need to add anything to each file, like a database of images.

I am still learning Filemaker. So that is why I am asking such silly simple questions that somebody else might know. I have two fat books for it but they just confuse me more Especially the default manuel !

So a simple tutorial would be nice for the constant computation. I will provide a file if needed but it is just basicly 500 files that all need to be readable in a master database that contains nothing just a read file

[tripdragon]

File ... Like I said. very simple but it is something that has to be able to read a lOT of files in it.

fm.fp5.zip

[Reed]

So are the 500 files .fp5 database files or some other type of file that you are tracking. Are these tapes some sort of media file? In that case you could just have one database where each record stores a reference to the location of each of the files. I still don't think I get what type of data is in the other files and why they need to be separated.

[tripdragon]

Further idea...

M file launch script . find and parse ALL files in said comon file. Pull data from fields, launch interface.

Filter in interface.

Now this FULL view is just for the admin and someon that wants to read EVERYsingle file. That there are a few that will need this. But for the launch of the interface file it will just be a filter method that will then pull from the main file(s) .

So the biggest question now is. Can FM6-7 do it ? Or will I need to do something else ? I could just work on a PHP parse script that puls data from tabdelimited files but I still need to work in filemaker as there are users that are just to familar with filemaker to let go so soon. But I am working at fixing this. Though I like Filemaker's ideals. And it's interface. But if the job to just to much for it .... hmmmmm

I am in hopes that you all can help...

[bruceR]

You are trying to solve the wrong problem. You have the wrong basic structure and you're trying to do something that you really really should not be doing. You should have two files. Tapes.fp5; and Tracks.fp5. That's how databases work. If you were doing a Contacts database, you wouldn't create a separate database for Jones, and a separate database for Smith, etc.

[tripdragon]

BruceR said:

You are trying to solve the wrong problem. You have the wrong basic structure and you're trying to do something that you really really should not be doing. You should have two files. Tapes.fp5; and Tracks.fp5. That's how databases work. If you were doing a Contacts database, you wouldn't create a separate database for Jones, and a separate database for Smith, etc.

Oh if it were only that easy!

///....

No it can not all live in two files. There are just to many files and sub files. gTo just make one show you tend to need 40 different tapes with footage and stock footage and clips and audio and lots of other stuff. Andd all of this has to be cataloged. Two files would simply fill up and slow down far to quickly .. not to mention the dependence that one wou;ld have to rely on such a file.

There has to be a way that alot of files can be prased in some way with filemaker.

[bruceR]

You are trying to solve the wrong problem.

This is NOT a Filemaker technology question. You are asking for a solution that does not require you to learn effective data structure. Anybody that helps you down that path is doing you a disservice.

You have the wrong basic structure and you're trying to do something that you really really should not be doing. [According to what you have said so far] you should have two files. Tapes.fp5; and Tracks.fp5. That's how databases work. If you were doing a Contacts database, you wouldn't create a separate database for Jones, and a separate database for Smith, etc.

Consider trying to get some help with understanding effective data structure. I can't see much factual basis for your statements. In your last reply you mention something you have never mentioned before - the concept of shows. It will work better if you provide a more detailed description of what you are doing.

Since you mention shows, then, I suspect a total of 4 files are required. Two that describe your tape library - and two that describe Shows and individual tracks that are used for a show. And as a matter of fact, yes, I have built systems that do exactly this.

[tripdragon]

BruceR said:

You are trying to solve the wrong problem.

This is NOT a Filemaker technology question. You are asking for a solution that does not require you to learn effective data structure. Anybody that helps you down that path is doing you a disservice.

You have the wrong basic structure and you're trying to do something that you really really should not be doing. [According to what you have said so far] you should have two files. Tapes.fp5; and Tracks.fp5. That's how databases work. If you were doing a Contacts database, you wouldn't create a separate database for Jones, and a separate database for Smith, etc.

Consider trying to get some help with understanding effective data structure. I can't see much factual basis for your statements. In your last reply you mention something you have never mentioned before - the concept of shows. It will work better if you provide a more detailed description of what you are doing.

Since you mention shows, then, I suspect a total of 4 files are required. Two that describe your tape library - and two that describe Shows and individual tracks that are used for a show. And as a matter of fact, yes, I have built systems that do exactly this.

Yikes! dude.. Take a breath.

I am simply stateing that for such a project that haveing all data in four little files will have those files getting really heavy and slow not after to long. The files will have items like movies clips and other heavy file siz data contained inside of them to send to clients.

Please to not berate me, I am simply trying to find an answer. I have desided to try other softwares as they seem to have a bit more data structure power to them. The Relationships with filemaker are good but there should be some dynamic Relationship system to.

No matter. I will seek else for the time being.

[Reed]

You don't have to store the actual media files in the .fp5 files, you would just store references to the files in container fields and the files won't get too big.

[bruceR]

I know what you're saying but there isn't any basis for it.

For instance, you state that files will get "heavy" because they contain movie clips, etc. Filemaker files prior to version 7 cannot contain movie clips. They can only be inserted as Quicktime references. The performance of the file has pretty much no relation to its content, though there are some cases where if you try to display all content at the same time (such as a list view) then performance can drop. The solution is to use form view, or any view that doesn't cause you to look at all content at the same time. If you are importing still images, (JPG for instance) they need to be imported, NOT copied/pasted. Or imported as reference. This will have a very big impact on performance and file size.

It will work a lot better if you can give some simplified examples of what you are trying to do.

[tripdragon]

BruceR said:

I know what you're saying but there isn't any basis for it.

For instance, you state that files will get "heavy" because they contain movie clips, etc. Filemaker files prior to version 7 cannot contain movie clips. They can only be inserted as Quicktime references. The performance of the file has pretty much no relation to its content, though there are some cases where if you try to display all content at the same time (such as a list view) then performance can drop. The solution is to use form view, or any view that doesn't cause you to look at all content at the same time. If you are importing still images, (JPG for instance) they need to be imported, NOT copied/pasted. Or imported as reference. This will have a very big impact on performance and file size.

It will work a lot better if you can give some simplified examples of what you are trying to do.

Okay. Take these files. And multiply them by 500.

It is just a start of the amount of files. . Eh stuff...

[Reed]

Did you forget to attach the files?

[tripdragon]

: files here ?

test2.zip

[tripdragon]

like I said they are basic nothng special , but each show has it's own set of those and more, sometimes a show will range in the number of 20 files for footage . each one has a different need and want to.

[Fenton]

What Bruce is trying to say is that the amount of "stuff" does not matter as much as you think. Databases were designed to consolidate the multitudinous into many and many into one.

A referenced file to FileMaker is just a small text field. Or, if embedded, a largish "blob," but it only shows one at a time.

FileMaker is disc based, not RAM based. It doesn't load the whole database into RAM, only what it needs at the moment. How much data is in the database is usually less important, for performance, than how much of it you're showing on the screen at one time, and how you're using it.

While I would be a bit worried trying to use v.6 for what you want, it sounds like 7 could handle it. Of course if media storage is all you're doing, then you might want to look at dedicated media databases, such as Cumulus or Portfolio. But if this is tied into a multi-function solution FileMaker 7 might save you a lot of development time.

One thing I haven't seen discussed, which might influence this, is how FileMaker 7 stores that "blob" data. I wonder if it is somewhat isolated from the FileMaker part of the database, hence less likely for minor corruption in an embedded file to hurt the database. That's what I'm hoping anyway.

[bruceR]

tripdragon said:

like I said they are basic nothng special , but each show has it's own set of those and more, sometimes a show will range in the number of 20 files for footage . each one has a different need and want to.

All standard database stuff that can be met by the recommended 4 file approach. Your statements quoted above present no contradiction to previous recommendations from me and others, all saying pretty much the same thing. This WILL work, and it involves very ordinary database concepts that you might as well take this occasion to learn. You will need to learn these things sooner or later anyway.

[tripdragon]

constant calculation

I know how to make one, but how should the constant calculation be prased ?

Like

data1 = data2

or

data1 + data2 +data3 ...

:

Please help in this method as I thought of another way to try this .

[Lee Smith]

A constant would look like

data1 = 1 and data2 = 1

HTH

Lee

[bruceR]

More detail please. What are you really trying to do?