Eduo

Cool. This can get me started and better understand the examples. Thanks. I'm off to bed for today, it's 5am here! Eduo

I did take a look at all three examples for horizontal portals I've found, including the business tracker and the ones in the forums, but I'm afraid I can't understand how they're made. I'm trying to see if there is any place that explains the portal (rather than just giving an attachment, or along with it, at least) to understand what's being done. I hadn't noticed I hadn't answered on the reports. Once I've got the database set-up for the basic display of data I'm going to try and set-up both a way for a user to record which figures (and what quantity of each) they have, as well as some rudimentary ways of forming teams (all figures have a point value, so setting up a limit could send the database into trying to find several figures in that team according to some rules). Other than that there's no other kind of reporting in mind. I had planned on setting up a listing of all figures in the same layout as the figure's stats are now being shown, but haven't gotten around to even finding out if that's possible (it's not exactly a portal, as the figure listing is actually the parent table of the detail listing and that may not be possible to do currently). I've already solved the other doubts I had about the images and the links too, they were much simpler than I expected, but then again the features weren't there when I last used FileMaker..: Eduo

It's not exactly a "need". It's more a "nice to have" for my cousin. It'd be easier to understand and, not only that, would make the grid much shorter (4 rows high instead of 11 rows high). Incidentally, after a lot of data massaging I managed to get the data files correct and could conceivably, right now, create the grid as required with a vertical layout in a portal (4 portals, actually, one for each category). Horizontal portals would make my life easier..: I have thought getting the portals by ColumnID (I have a field with columnID, 1 to 11), but that'd mean making the 11 relationships again (which admittedly is better than 44, but is still a little overkill) And I would have problems of other kinds (like sorting within each portal). While I think about the layout I'll try to work the vertical layout into the database. Thinking about it it shouldn't be a bad thing anyway, just a different way to see the data. A bad side effect of the "new order" of the database is that the FP7 file now is much bigger, weighing in at 3 megabytes without any graphics in it. And this is happening even tho' I made sure to not include "zeroed" fields (if a figure had only stats for three clix I didn't add the rest of the clix). Any way, thank a LOT for all the help. This has been an enlightening thread and I know it must've been frustrating for you (I can only imagine your face when you first opened my original file..: I'll try to work on the layout now, I have thought it should work as well and probably look a little more compact (an original goal) with a smaller vertical grid instead of a horizontal grid (literally rotating my original grid 90 degrees clockwise). When I'm done with this I'll try and find out how can I use an already-filled field to become the reference for external image files into containers (the images for the figures themselves, I've got the path already in a field) and how to convert a currently-text field into a clickable URL (the URL already exists in the field). Thanks a lot again. If you keep subscribed to the thread I'll post a sample of the file afterwards in case you want to take a look at it. Greets Eduo

Sorry for the delay in answering. Left town for a day. (I should add that I've taken your advice and have been actively looking for some tutorials and training on data normalization and database design for relational databases) Ok. So it'd be better to leave the dissimilar information in a flat table while the clix themselves in a separate table and reference them by column, meaning that I'd ask, for a specific figure, the value for Click1 where the type is (for example) Speed, right? I did think about this and started doing it and it's actually simple for me to do and removes a LOT of redundant blank fields and data, but here's where my knowledge of FileMaker is limited, as I'm not sure how to display the figure's clix in a table-like manner (the same way it was shown before, actually). In PHP I would do it with a query, running a loop from 1 to [highestColumnNumber for the figure] and then showing each of the field's, padding the unfilled part of the table with blanks (for aesthetic reasons in the table). This above is what I can't figure out in FileMaker. I know I can't make this selections from the layout itself, but from a previous field/calculation table but I'm not sure how this is done. Eduo

I thought as much. Information doesn't change per se, but I might need to pull information from within the data itself. I've been thinking about this problem, and in the end I've realized that clicks or not, colors or not, in the end it should be a flat-file database for the heroes themselves. All those 11 click numbers (times two) and their corresponding colors are not different from a flat-file database of products with their characteristics (say, like a people database that lists their birth date, their sex, their hair color, etc.) So I'm probably going to use a flat file for the clix (although that does mean almost 100 fields for it). My only doubt is now how to use a single powers table for reference of 44 power colors (I have 44 fields in a single record for powers, 11 for each category, and each of these has a number, which has a reference to a color power, as you already saw). I can't think of any way to link these powers to the colors database, but I don't think I can do it without 11 iterations to the colors database. I also have to admit, I think I might have mentioned this before, I'm at loss with the use of global fields. I can't get how they work. I haven't seen an explanation of them anywhere that gave me a clear understanding of how they work..: Thanks for the help and the tips, too. O think I'm at an even more basic level in FileMaker than I expected (my previous attempts, although successful, were admittedly easier than this!). Eduo

I've been browsing around and it seems repeating fields are NOT the norm, but the exception. Why are repeating fields better in this case other than to simplify relationships? Also, how can I import into them? Is there any sensible way? Eduo

[DELETED] Broken Post PHP

Wow. I hadn't noticed there was an attachment, so involved was I in trying to explain..: Thanks a lot! This is what I needed! I have to admit, and I think it's clear: I have ABSOLUTELY no idea exactly how the global field works. Everywhere I've seen seems kind of confusing to me. This is a great starting point. I'll take it from there. Thanks again and thanks for your patience! Eduo

Actually I want to do two things. One of them is like the one I linked in my first message and which, messy as it is, shows my sample database: A figure's full stats. The second thing I want to do is be able to set-up two other groups, one of them the figures owned by a person, and the second would be teams based on those owned figures. I think I can do the other layouts but I wanted to find the most efficient way to build the main database. I can manipulate the data in any way to fit the best way and then import it into the database, but I *know* the design of the database will affect greatly what I do with it in the future and also the "cleanliness" of the overall file. That is what I was asking for. I'm severely stumped and can't think of any way do it better. I have already tried the one I sent (tens of tables) and I'm also trying right now with a second method (which has just one table for all the figure's stats) which isn't proving any better. All the data is fixed and will be locked. It's just for team building and statistics. Eduo

Bruce: I know it's a mess. One of the reasons it's a mess is because the original data files were so as well and I tried working with them without modification. I've remade the thing and have now only two tables, actually, although several instances of these in the relationships table. I did say I needed help, tho'..: That's why I especifically asked for what to do and what had I done wrong. Anyway, I'll keep going at it and figuring things out. Considering there is nowhere in Spain where I can get a course or even a book I'll do my best until I can get one from overseas. Thanks anyway Eduo

BTW. After my last message I realized that if the data is not going to be changed by the user (is just a reference table) *AND* it's always going to be laid out in the same way for everybody THEN there was no reason for it not to be a single MAMMOTH table. 1 table for heroes, containing the stats and the 11 clix with values and another 11 clix with powers. In total instead of 12 tables (one main stats, 1 for each clix) and a mess of relationships I have a single table and no relationships. *sigh*, again, thanks for forcing me to put this in another light. The database just got much simpler. Also, while in this. I have tried putting the images to the figures by references. The references are really simple: "images/"&HeroID"*.gif" I have tried every way I can think of and I can't make the image display. I've defined the field as a container with auto-entered data specifying the path and I have also tried creating a calculation field and the result being a container. In all cases I get a container box with the TEXT to the file in it. I'm missing something basic and can't figure out why. And whatever I'm missing is being taken for granted in all the forum topics I've tried searching for here..: Eduo

This is an interesting idea and I hadn't thought about it. I think you stare so long at a problem you can't help not noticing any way to do it differently. Thanks for helping me to see the problem, almost literally, sideways..: I'll do this to see how it goes, it's not like this is for a work project or anything..: I'll try with a smaller clix database (3 clix or so) and see how it works. I'm not using portals right now, but I plan on making a layout where the list of all the heroes are visible (a portal, most likely) and upon clicking any of them you see, in the same screen, the stats of the selected item. If this works then I might expand this layout to include a "team" portal that shows "selected" heroes to form a team. This would mean two portals and a detail view all in the same layout so it may prove to be a challenge.. I accepted to do this for my cousing also because that will be a way to get myself acquainted with FileMaker again, since not using it intensively for six or more years.. Thanks again. Any further tips would be greatly appreciated. Eduo

Bruce: I posted the question as well in the relationships forum, after a suggestion to do so. I also posted a sample attachment with one of the ways I had been able to make it but I think it may not be the best way. This is the link to the thread: [url="http://tinyurl.com/yv8ay"]http://tinyurl.com/yv8ay It's different to SQL in one way, and that is that I can't put the data in the table and manipulate it in the output report. I have to do the calculations beforehand if I'm manipulating data and this little different is making me harder to picture the database as a whole beforehand (which I know is the correct way, by the way, but I had thought this project would've been simpler, what with the fact that no data has to be entered..: Eduo

Ender: Actually the data is fixed. Is a database generated by the actual stats in the figures and they never change. The data is there for maybe later filling out owned figures, creating teams, etc. As all of these would either just be pulling information from the fixed figure database or entering data in a new table (a "teams" table, or an "owned" reference, or even "loaned) I just wanted to know what the best way would be to store the data (most efficient, if you will) both in terms of performance and in terms of pulling the data afterwards for review (like in the sample above. I already have a quick and dirty design where I'm using the 4th option, but I'm considering alternatives as I'm not finding ways to manipulate the data afterwards. I'm attaching my Heroclix database as it currently is and maybe you could take a look at it to understand what I mean about the spidery relationships. It's become unmanageable. I also wanted to know the best way to set this up so as to be able to afterwards pull information more easily. Also, if you see the database and wonder why is the data so weirdly referenced it has a lot to do with the original Excel worksheet I had to take it from. I had never seen so weird Excel macros in my life and the way those macros were pulling the information from blocks of text (not tables) I can't even start to explain it. THanks for the help. I haven't touched Filemaker in enough time that the experience is humbling me..: Also, keep in mind that the attached file is a subset of data, only 100 records or so. The original tables I'm using have 1028 records for each of the tables (that is, for the hero table and for each of the "clix" tables). eduo FMClix small.fp7.zip

[Double Post, Slow Network, Deleted]