Jump to content

apd183

Members
  • Posts

    10
  • Joined

  • Last visited

apd183's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Ah, got it... there's nothing in FileMaker keeping it from working, but it's not the normal type of relationship one thinks of. In this case I want all the children to be related to the parent Globals table, so a relationship with globals 'works'.
  2. Do you mean that only 'date01' will be calculated and 'date02', 'date01UI', etc are not? Some things to check: - Make sure the ID field in both tables are the same type (number, text, etc). - You may have just shortened it because of the forum, but table::field references have two colons: 'class::date01'
  3. Then how is my Schedule_Databse>Globals relationship working? Both match fields are globals. For the Globals>Convention Information relationship, the parent match field was a global and the child match field was an indexed text field. Should this have been working?
  4. Ok, I've got it to work with a few changes... After further testing I realized the relationship between Schedule_Database and Globals was working correctly, but going from Globals to Convention_Information wasn't working. Looking at the Globals table, the Year field was a global text field, relating to a regular text field in the Convention_Information table. Changing the Year field from a global to a regular text field makes the relationship work every single time. At this time, this is an acceptable solution. This brings up a new question: is this normal behavior? Should a relationship between a global and regular field work? I know relationships based on two globals work (as that is how the Schedule_Database>Globals relationship is set up), so why shouldn't this work? I will need to do more testing, but this appears to be a bug, no?
  5. Hello Ugo, In reality, the date fields could be called Day1_Date, Day2_Date, etc. In this case the event will always and forever run from Wednesday to Sunday, so that's why I named the fields as such. The reason I'm trying to set this up like this is to keep the maintenance of the file from year to year easy. If I put the actual date in the Schedule_Database, I would have to change it and every calculation/script that uses it - not an easy task in this file. This way I only need the actual date for display purposes. The refresh script step (flush or no flush) does not appear to be solving the problem. Thanks for your reply!
  6. Hello all, I've run into a problem and I cannot find what the problem is. I'm not sure whether this falls under 'relationship' or 'define fields', but the problems in this board looked more like mine. Any help you can provide is greatly appreciated... Scenario: (also see attached picture) I have a list of schedule blocks for an event in the Schedule_Database table. Each block has a day number, which is what day of the event it occurs on. When displaying data to users I want to show the actual date, so I have the Convention_Information table that holds this data. The Convention_Information table takes the date of the first day (that is entered manually) and calculates the other dates (each date in it's own field). I then have a Global table where you enter the current year. This determines which Convention_Information record we look at for the dates. Schedule_Database is related to Global via a dummy global field with the same data in it. It is currently an = relationship, but i've also tried the x relationship to no avail. Global is related to Convention_Information via the the year field. This is a manually entered text field. The to display the correct date, I have a Date field in Schedule_Database that is a calculation: Case( Day_Nbr = ""; "ERROR"; Day_Nbr = 0; Convention_Information::Wednesday_Date; Day_Nbr = 1; Convention_Information::Thursday_Date; Day_Nbr = 2; Convention_Information::Friday_Date; Day_Nbr = 3; Convention_Information::Saturday_Date; Day_Nbr = 4; Convention_Information::Sunday_Date; "NO MATCH") The Problem: This calculated Date field will not display any data most of the time. When you first open the file and look at records from Schedule_Database, the Date field is blank. I have, on occasion, been able to get the date field to show, but the method of doing so is not reproducable: I can do the same exact thing many more times and it won't work. Once the dates show up, they stay as long as you have the file open. Any idea on what is keeping this calculation from working all the time? schedule_db_diagram.bmp
  7. The 'Run Script File' option in FMServer is for scripts that you write (apple script, vbscript, batch files) to do things on the server. A simple example would be copying your backups to another computer on the network. As Old Advance Man said, it is not for scripts in your FileMaker databases. For the scripts to show up in the Admin panel, you must place the script file in the Scripts foler on your FMServer. It's in the same place your default Database folder is located in the FileMaker Server folder.
  8. I don't know if this is the same whitepaper you spoke of above, but this tech brief was very helpful: http://www.filemaker.com/downloads/pdf/techbrief_fm8_server_auth.pdf It applies to FM7 as well.
  9. I'm fairly certain that the FMPro licenses do not apply to IWP. The licenses are only for each copy of FileMaker Pro you have running at one time. Conceivably, as far as the license is concerned, you could have 1000 people hitting the database through IWP at any given time. Examples:(assume all machines are connecting at once) ->1 client with FMPro serving via IWP, and 10 machines connecting over IWP - 1 FMPro license ->1 server with FMServer, and 10 machines that connect over IWP - 1 FMServer license ->10 machines, 1 server, each with FMPro installed and connecting to the server through FMPro - 10 FMPro licenses and 1 FMServer license
  10. I am having this same exact problem with CWP using FX.php. I have two database files: a directory file, and a signup file. The directory contains contact information for our members. In the signup file, a member enters their number (online - a page using FX.php) and a record is created. Fields that are stored in the directory are looked up so the user doesn't have to enter it again. In this two file setup, the lookups do not occur. In fact, NOTHING that relies on the relationship between the two files works (calculations, scripts, related fields, etc.). Both files have the same user and password for web access, and I even tried giving the account full access, to no avail. I know the relationships are good because everything works within the FileMaker program. The interesting thing is, when I do this with all the tables in one file, it works perfectly! What is going on in the two file setup that makes this not work? Some additional notes: - This must stay a CWP solution. - This must use the two file architecture. We have many auxiliary projects that use the directory information, and we do not want to put everything in the directory file. Too many people working at the same time.
×
×
  • Create New...

Important Information

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