Hurican

Ok, here's one that has been throwing me for a loop for over a week. I am building an event system, and have the dates as calculation fields (works fastest that way). But the Events themselves are from a relationship based on month and year. I would like to be able to make each day field into a button which gets contents from "self", that day so as to compare it to the date and pull up either previously entered events, or have a request to enter a new event. I'm hoping to do this from one script as opposed to having a script written for each of these fields.

Luckily I don't needs AES level security for this file. , but I would like to know. What are some of the ways that you've seen in which startup scripts can be broken into?

I am making progress. The startup script in the Menu file sets a "AccessSwitch" in the file that holds the account information which is related to all other files using a cartesian join. Depending on Account accept or deny arguments in the Menu file, this switch is set to "on" or "off" or "" (removing values at close of file). There a separate startup script in each of the user files wich looks at this value to determine how it will open. I think a variable would work (provided a local variable can be seen through a relationship, as long as the particular script is active... I have to check that out). But essentially, the field is only switched "on" for the menu script, which is cleared after the file is opened. A logistical nightmare to be sure, but a cool challenge. Thanks for your help.

" Whatever this construct is, it is not The Separation Model as that term is correctly understood. When you say "...restrict access..." what do you mean exactly? " You're right. This is not really a separation model in the true sense of the term. I should have not used that terminology. By restricting Access, I mean if the user clicks on the file directly, they will not be able to open it at all.

If set on the desktop, then the only file visible would be the Menu file. In accompanying folders, there are the user files, and in a separate folder, the file that contains security information. The data exists separately in a data folder to be imported dynamically depending on which file is chosen. Yeah I know it is a weird solution, :-) it is based upon a dynamic templating system. I want the users to only be able to access the files via the Menu file, if they should happen to go into one of the folders directly, to disallow access and take them back to the menu file.

I am using what could be loosely called the Data Separation model. This is not a file that will be served or published to the web, it will be compiled into a runtime eventually. I have the "Main Menu" file in the main directory, another database in it's own directory which holds account, and registration information, and a third directory which holds all of the files. I would like to be able to restrict access to the Files, and the Accounts database, so users can only open it through the Main menu. I know it cannot be that difficult but it's something I'm missing. Ideas, or something to point me in the right direction would be greatly appreciated.

Basically, I am looking for tips, and references on how to use a filemaker file as a scripted "import engine" to handle the moving of data from .mer files to a new set of files without creating a large mess... basically using the engine file itself to handle all of the functionality. I understand scripting and relationships fairly well, my main trouble is updating the new files, currently held as tables in the engine only by file references. I think I just need a push in the right direction, but will take all the help I can get. :-) John

If you are using the Get(PrivilegeSet), then depending on how you the database opens, you may have to add a relogin step. You might also try the Get(UserName), or Get(SystemIPAddress). The user name is specified in the program under Preferences.

I need more info too. Are you importing into multiple files, multiple tables in one file? etc.... There is a script step that allows you to import files. You might be able to run the import script for the first file, have it run another script to import the second file, then run the next script, etc... I have never tested importing from mulitple documents before, but it should be possible. If you link enough of the import scripts to do say 5 at a time, then all you have to do is go back in and change the file names in those scripts for each import set. Definitely make a copy before you try this out though.

Thanks Queue! That link has given me a structure to work with. Even though I have alot to work out, and most likely re-modify some of my relationships (to get better performance), I should be able to make this work. This database is regarding statistics, so there will be alot of numbers flying around. :-)

Here's a challenge. Say you have a fields and any number of records. This is a number. These numbers are not unique. The same number can come up many times throughout the records. Within a found set based on a date range, how would you script (or calculate) the Count of the number that comes up the most (Max), and then display the actual number in a Results field?

It gets interesting though, when in 6 there is latent but as of yet... unnoticed corruption, and you try to convert it to 7. Then you can get unexpected results, and the file will most likely have to be recovered and compressed pre-conversion. The best thing to do though, is to export to text file, save a clone, and import into the clone. Once the OS gets ahold of the text, all extraneous artifacts are removed.

1) Create a new blank database. No fields on it. 2) Goto scriptmaker. Create a new script and put these steps in. - Allow user abort [on] (Or as Vaughn says, trap for a modifier key) - Open File. Specify, add file reference. Click on the remote button and find your served file. - Close File [Current File] 3) Goto File > File Options (When opening this file, Perform Script)... and find your script. 4) Put the database icon on your desktop and you're done.

v5.5 and v6 are cross-compatible with OS9 and OSX. v5 and before are OS9 only. v7 is OSX 10.2.8 and newer.

Try installing the v2 udpate patch for server. This has solved the issues with many of my customers.

How are you viewing the files in FMPro? With a container field? Is this images or files, and are you storing them in the database, or just storing a reference to them?

I think that I have seen this before. I believe that it is an option in the part setup. Empty layout parts should be removed first. Then go to part setup and check this option. "Allow part to break across page boundaries". Also check the box that then becomes available. "Discard remainder of part before new page". I think that this will take care of the blank pages deal. Sometimes if there is extra space not being accounted for, the printer (due to a tough time with translation between the application and the printer drivers) will interpret this as a blank page, and typically spit out one blank per record. By looking at the numbers in your post, it seem that this would be the issue. Hope that helps.

Something that I might suggest would be to put these images in a dedicated table within the same file. FileMaker 7 has about 8 Terabytes of storage per file. So far as I know, no one has come forward and said that they tested those limits, but I believe that you have a way to go before you hit performance dogging. With images, backup times signifigantly increase. Network traffic and server usages are affected, but not as badly. Hope that gives you some additional info...

Pay more attention, drink less caffiene. My new New Years resolution.

Hey Billy, If you want to convert up to FMPro 7, there is a script that could replace this alpha for you. What you would do is create a loop to bounce through all of your records, and basically create an if statement specifying to replace that particular char with a Text Formatting function, which was not available in 6. You can specify everything right down to the font face (What kind of font you want to use), to text colors and sizes. That way you won't have to bother exporting to word processors and jumping through those extra hoops. Version: Developer v7 Platform: Windows XP

I don't think that they will change that, as the Get (FileName) is specified for just the name of the file itself. The filepath is much less restrictive. I wonder though, since the Get (FilePath) is there, what would be a better use for the Get (FileName)? Version: Developer v7 Platform: Windows XP

If you want to edit an opener file, the best practice is to Allow User Abort [On], pause the script for more than 1 second (but not too long, because the served file may take a couple of seconds anyway to open). Hit the escape key repeatedly. That will stop it. (Unless you do have User Abort [Off]. Then you might be able to break the path by simply moving the launcher file to another directory. (I have not tried that though, but I believe it will work.) Version: Developer v7 Platform: Windows XP

Hmm, without a doubt it makes changes on my layouts, changing graphics, wingding fonts for cool buttons and field labels/text. I wonder what the difference would be.

I definitely agree on the font that is best for cross platform functionality is Verdana. Has been my favorite font for a long time. :-)

http://www.microsoft.com/typography/cleartype/tuner/1.htm This is the link to a clear type tuner. It may help a little more. I would bet that because of all the attention this is getting, FileMaker is rushing for a fix of it. I personally love the program, and can get around this problem for the time being when considering that FileMaker based its 7 re-write on user input.