Lemur

Hello, I have a portal that currently shows all related records (as it should). Sometimes, however, I'd like it to only display certain records. Every record in my related file has a field called "active" - this displays whether the player is active or not (with a "Yes" or "No"). I would like to create a button that - when pressing it - will only display those players listed as "active" in the portal. I can then have another button that will reverse this (i.e., do the default - show all). What would be the easiest way for me to set up this "find?" -- I can then throw it in a script, for the button... I'm using FM 5.5. Thanks! Chris

I was able to solve this problem. As I mentioned, I needed to denote the most *recent* record in the file. Once I did that, and changed the relationship to search by that field, instead, I was able to get the proper information to show up. Thanks to all who helped! Chris

Hi Michael, I now know why it's not working, but I've no idea how to fix it. Let me go into more detail (and step away from the easier-to-understand "calorie" scenario, and discuss what it's really doing). The database tracks scores in various games played. Each game has it's own id#, and then, each person has his own id# (and name). So, to see game1 / Bob, the id/name field would be 1Bob. In addition, for the FIRST time someone has played a game, there's an X-Field (which denotes their first playing). So, someone playing game 1 for the first time would have X1 with their record. Someone playing game 2 for the first time would have X2, but someone who had played previously, would just have "2." I did this because I wanted to isolate records to be pulled into the portal. Since the fields I want to display are all calculation/sum fields, it didn't matter which record was selected, and it was easiest to identify the 'first,' (otherwise, I'd get *all* records, which I didn't want - I wanted each person represented once in the portal). The relationship I've set up is on the X/game id relation (so, in the file with the portal, there're different records which pull related records X1, X2, X3, X4, X5, etc. The relationship is the X/game id in the portal file to the X/game id in the related file, and then, it's sorted, descending, by the score. The problem with that, is it's ONLY looking at the Xgameid, and only if there's an X - so, it's restricted to the first time people have played (which explains why my new scores are only being shown from the first record someone has). If I change it to JUST GameID::GameID, I can sort it by sequence, descending, but, then, it displays ONLY from the last record (and not from each person), for some reason. What I need, I think, is to figure out a way to denote the most *recent* record in the main file (maybe a reverse gameid/xfield) and then, relate on that field to the portal. Otherwise, I don't know how to get the information I'm looking to display to show up. Chris

Hello, I have a database that handles a slew of "running totals" (for argument's sake, call it 'calories consumed'). Let's assume, in this database I have 8 people listed, and I have all their calories for each meal during a week (21 in total). If I want to have a portal that shows each of the 8 people, with the total calories consumed (i.e., the total from the most recent record), *sorted* in descending order of total calories - how would I be able to do that? When I set up a typical portal, it seems to pull the data from the first record in the database; not the most recent (which contains the information I need). I'm using FM 5.5 -- it seems like there SHOULD be a way to accomplish this, but I'm drawing a blank! Chris

Hi, Yes, I saw that one too...it's pretty close. The problem is it relies on serial number (which is fine). And, then, each record has a 'previous serial number) which is the current serial number -1. In my case, there may be hundreds of serial numbers before the same 'game id' comes back. Chris

Hi, Yes, this is very nearly what I want. There's only one difference -- I'm not looking to create a running tally of ALL the records...just the ones that are 'related.' Take a look at the sample file (which I've updated a bit from the first post). You can see in Record 1, that "Bob" playing game #1, started with a rating of 5000, and added 100 points. Bob shows up again in Record 5, but playing a different game (game id #2) - again, he starts with a rating of 5000 and loses 33 points. His final time is in Record 9, playing game #1 again. What I NEED is for the "Base Rating" in Record 9 to reflect the "New Rating" from Record 1...so his starting rating would be 5100. You can see my attempts at relationships and calculations. Obviously, this is not correct; but I think I'm on the right track. The "Lookup" from the LULAST file you showed me cleared things up somewhat... Thanks! Chris Sample.zip

Hello, I'm trying to determine the best way to set up a running calculation that uses previous records as the base. Imagine, for example, 4 players play a game for the first time. The base score all players start with is 5000. During that game, Player 1 gains 100, Player 2 gains 50, Player 3 loses 50 and Player 4 loses 100. The NEXT time they play the game, I would like their base scores to reflect the changes from the last game (so, new scores would be 5100, 5050, 4950, 4900), and so on. I've been able to set up relationships within the file to allow the 5000 to be placed, and for all the computations. The problem is, I'm unable to set up a calculation for the second playing, without creating a circular reference. I have attached a sample file, to illustrate what I'm trying to do. I'm using FM 5.5 Thanks for any help or ideas you can provide! Chris Sample.zip

And, in other words, it will always pull from the most recent? always? I can definitely set up a script to sort by date upon closing the table -- that will ensure the newest is the most recent.... Chris

Hi Vich & Fitch, I already have them in separate tables - in fact, the whole 'database' is 9 tables, with 3 join files. I know I can get it to work - the hard part is telling it to pull the MOST recent base value to work from. How would you do that? i.e., assume the following example: Game 1: Base value 5000, gain 33, new base value 5033 Game 2: Base value 5033, gain 50, new base value 5085 Game 3: Base value 5085, lose 25, new base value 5060 How do I ensure that the Game 4 base value is 5060? I can do a relationship in the table, but how can I direct it to pull the base value from the most recent entry, and not from Game 1 or Game 2, for example? Thanks!

Whew...let me see if I can explain this properly, and then, see if it's even possible. I'm looking to set up a running calculation for my boardgaming group. One formula basically compares the scores of the various players, and determines how much each player will win or lose. That total affects the previous "base" total, and a new base total is generated. So, for example, let's assume all 4 players start the game, tied at 5000. They're playing Monopoly. At the end of the game, the formula determines that the 3 losing players should lose 33 points each, and the winner should gain those 99 points. For the NEXT game, their scores would be 5099 and 3 players at 4967. This is only a running total, assuming they play the same game. If the next game is, for example, Sorry, they would all start over again at 5000. But, if two of them played Monopoly a year from now, they would start with their new base numbers (and, the new players would start at 5000). I don't even know if this is possible. The hardest thing I'm trying to wrap my head around is how the program will now to pull the 'new base' from the NEWEST related record (all the records are related even within the same database). I'm sure I'm not explaining this 100% accurately -- but, does the basic premise of this sound like something I can accomplish? Can anyone point me to a link? I'm using version 5.5. Thanks! Chris

Ah!! Yes... So, what's happening is NOT that it's noticing that, for example, that calculation field is changing -- it's saying, 'hey, since one of these records changed, we'll select ALL the records that have that same identifier (i.e., 350Chris). OK - that's a good workaround - it's not checking for what I THOUGHT it needed to check; but it's accomplishing EXACTLY the same thing. Very cool..... Chris

Yes! Yes! Yes! That does work -- to test it, I set the clock on the computer ahead, and adjusted some sample records...worked great. Can you explain how it works? I'm still a little lost on that - why does it know the modification date (even though it doesn't change) is changed for those fields that are calculation only? Thanks again! Chris

Hi John, I saw you had your email addy listed in your profile; so I did zip up all the files and sent them to you... (be forewarned, in the playerplayedjoin file (the one I sent you earlier) the bottom two fields in creation order serve no purpose currently - I'm trying to figure this out, and those were my 'test' fields). Chris

Hi John, Actually, I didn't forget to reattach -- I just posted simultaneously In any event - I can't reattach them all - the total is over the 1mb limit the site allows. But, you don't actually need the other files (I don't think) - if you do the steps I mentioned, I'm 99% sure the information will all be in that one file I sent you. It'll probably give you some error messages, because they are all relatable; but, essentially, the other files have no bearing on what I'm trying to accomplish here. Chris

Thanks John... I've been going nuts today trying to figure out an easy fix -- seems like it should be fairly easy; but I guess I'm wrong Chris