Jump to content

Chappy.Cole

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Chappy.Cole

  • Rank
    novice
  1. I don't doubt that you are correct within the realm of tools like FMP or Access, i.e. software that is both an application for developers and for users. However, in my experience with software development using programming languages this problem is non-existent. In that world, the developer uses the language and related tools to create the source code and then transforms the code, via compilation, into the software that is for the user. Since the developer starts at ground zero and builds to a pre-determined set of features there is no additional work to be done. I'm not saying that su
  2. I probably am not explaining myself thoroughly. My database represents a season of play. The sequence of tables is: -> Events : contains a list of the major events within a season -> Tournaments: contains a list of the individual tournaments, which involves 12 teams (out of hundreds). Altogether these tournaments comprise one season event -> Pools: contains information about the pool-play section of a tournament which is quite different from bracket-play, although both are composed of matches -> Brackets: contains the information about the playoff brackets at the end
  3. So, I have been working on a volleyball tournament database. In each match, there are 3 teams involved: 1) Home team ; 2) Away team ; 3) Referee team. Each team in any match will at some point be performing each of the roles, i.e. every team is sometimes the Home team, sometimes the Away team and sometimes the Referee team. My database has a Team table and a Match table. When I am designing a layout to show a summary of a match, I have the need to display information about each of the 3 teams. I know that I can achieve this by having 3 TO's of the Team table, each related to the Match
  4. 'Comment' is quite right about my plan...The TO one selects when creating a layout merely establishes the base table the layout displays and the network of connected TO's that are related. It does not, however, use any relationship. Essentially, this is a case of you wanting to have your cake and eat it too, i.e. Cake) All records, active and inactive, exist in 1 table: People Eat it) Layout shows only one type of record based on status without chance of user getting to other type of record. As you know, you can temporarily subset the records via a 'Find' (which the user can
  5. There's one pitfall with the 'Mod ( number, Sign ( number ) )' method: Sign can return 0, which, if it does, Mod would be attempting to divide by 0, which is undefined. Of course this is a special case; however, this is precisely what we must always be worried about, i.e. the special cases! Well, excuse me. I just tried using the Mod & Sign calculation and it correctly calculated the value that scottvaughan wanted, e.g. number = 27.385 ==> calc. = .385 number = -17.129 ==> calc. = -.129 number = 0 ==> calc. = 0 That concerns me because FileMaker is ma
  6. Your skill level says, "Expert", so I suspect that I am missing something as I ponder your issue... Anyway, it sounds to me like your solution is: 1. Define 2 global variables: gActive, gInactive. 2. Establish their values to whatever you use for your field Active, i.e. you set them to 1 and 0 respectively. 3. Create 2 Table Occurrences of your People table: 3.1 Active_People 3.2 Inactive_People 4. Create 2 relationships to your original (or any other) People table occurrence using the gActive field from the Active_People table to conne
  7. Ok. After further tinkering I think I have a more refined inquiry regarding my problem. If one has a group of tables like my Continent->Country->State->City example, where all Country records relate to exactly 1 Continent record, and so on down the line, is there a standard rule for the use of key fields? What I have now is: --> Continent::continentId --> Country::countryId, fk_continentId --> State::stateId, fk_countryId --> City::cityId, fk_stateId However, another possibility that came to mind, and would solve my problem, is: --> Conti
  8. The most obvious thing - which I think is in error - is that you have the "Go To Portal Row: Select: Next: Exit after last" in the loop *before* any processing steps. Unless you intend to skip the 1st portal row, the "go to next" step ought to be immediately before the "End Loop" step. The other things that "appear" to be in error is the absence of any step which adjusts the amounts remaining after applying a payment. If I'm right about this, then your script would apply the lessor of the client's check amount or the invoice balance, to every row in the portal except the 1st. Since
  9. I'm not an expert; however, I have been a professional software developer and I have used Filemaker Pro since version 3 up through 7. I created my own version of your scenario (making assumptions as necessary) and I was able to achieve your goal - sort of. My solution has 2 tables: 1) Employee ; 2) Safety. However, there are a total of 8 Table Occurrences and 6 relationships. Essentially there are 2 Table Occurrence Groups (TOG's): 1) the Employee table connected to the Safety table with 3 separate relationships via the 3 fields in Employee that each hold a copy (i.e. foreign key fi
  10. I have a scenario that which requires at least 4 tables which can be represented as such: Continent (which is a superset of) Country (which is a superset of) State (which is a superset of) City I would like to be able to create relationships, value lists and layouts that enable the user to view the information from the top (Continent) all the way down (to City) (succeeded here already) *AND* from the bottom (City) all the way up (to Continent) (failed here). My failure is not that I cannot figure out how to accomplish the task, but rather that the solutions
  11. I attempted to open a FP version 5 file, which has a password for full access priveleges, using FP version 7.0v3. FP7 prompted me for the name to save the old version under and where to save the converted file. Once I'm done with those, it asks for a username and password. I enter what I know to be the username and password that I originally used, and it rejects it. Other possible factors are that, since the last time I worked on the FP5 file, I have upgraded our OS to Mac OS X 10.4.7. Also, my hard drive crashed and I had to take it to a specialty place to get the files recovered. M
  12. Thanks for the welcome! Thanks for your reply also. I'm already glad I joined this forum community. It's possible that I might need some of the other tracking fields that you mentioned, but for now, I just want the basic feature of customer info, issue description, current status and history. Thanks for the ideas and help. Chappy Cole
  13. I have occasionally wanted to track the history of some bit of data. For example, right now I want to create a db which contains the following fields: -> Customer Name -> Customer Phone -> Customer Issue -> Current Issue Status -> Current Issue Status Date -> Current Issue Status Description -> Issue Status * -> Issue Status Date * -> Issue Status Description * in which, the last 3 fields with the '*'s, can repeat endlessly. In other words, as time goes on, for any customer issue, the status will change some unknown numbe
  14. I started using databases *after* learning about relationships and being a programmer. So, I avoid repeating fields entirely. Since this feature has persisted through 5 generations of FM that I have used (3-7), I guess it has some use. Can someone give me an example or 2 of a good use of repeating fields?
  15. Is it possible to encapsulate a group of FM files - i.e. tables - into a coordinated, single point of entry, application? That is, is there a way to have a group of related FM files connected so that the following things are true: > There is only one entry point into the "application", i.e. the first file & layout the users see is always the same > Permissions and other security features can be estabished at the application level, i.e. not on a FM file by file basis > Scripts can be shared across all files in the application without have to re-write them for each f
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.