Barbecue

I thought about doing that, but the problem is that multiple requests might be processed simultaneously, so instead of a single record, I'd need to support multiple records, which would mean creating some sort of session ID and using that. I was hoping there was already a way to do this built into the API, but I guess there isn't. I am thinking the easiest thing to do may be to just pass all the values as a single string script parameter and then parse them out in the script itself.

I am experienced with both FileMaker and PHP, but I am new to the FileMaker PHP API, and I'm trying to find the easiest/best way to implement a sort of web service. I have a FileMaker script that currently does most of what I need, but I need to run it via the PHP API. A remote server submits a single http request with several variables to the FM web server, including an ID number. These values are stored in global fields in a FileMaker table. A FileMaker script then retrieves these values from the global fields, and searches the table for an existing record with the same ID number. If there is no record with the same ID, a new record is created and populated with the submitted values. This single record is returned, including additional values that must be calculated by Filemaker. If there is already an existing record with the same ID, the existing record is compared to the values submitted by the remote server to see how different they are. If the values are the same, or similar enough, then the record is considered a match. The values from the existing Filemaker record are returned. If the ID is the same, but the differences in the other values exceed a certain threshold, then the record is not a match, and an error is returned. The current script works by storing the remotely submitted values in global fields, then operating on those. But globals are session-specific, and from what I've seen, it doesn't look like the PHP API supports persistent sessions. Each transaction seems to be a separate session, so the globals are lost. I've read that it's possible to have globals persist for an entire session with XML or XLSLT, but I suck at XML, and really can't afford the time to learn. Is there a simple way to make globals persist for an entire session with the PHP API? Failing that, is there another simple way for me to use the existing script?

Probably the simplest thing would be to change Original_Service_Company to a text field. Give it an auto-enter calculated value of Service_Company, and make sure the "Do not replace existing value" box is checked. Unstored and stored calculations both recalculate based on changes to the values they are based on, but the value of stored calculations is that when a new value is calculated, it is actually stored, so it can be indexed. That lets you do things like use them for relationships and fast finds, which unstored calcs can't do. The disadvantage is that they take up space in the database, while unstored calculations are computed on-the-fly, so they use only a trivial amount of storage.

Thanks Comment for providing the missing link. I was basing a join off a calculated field using the List() function to identify which values had already been populated. I've done this in the distant past without problems, but this time I couldn't get it working. Apparently this was due to a change in how FM9 treats number fields versus earlier versions. Comment's example simply appended a static number to the end of the list calculation. As soon as I did the same, my own portal started working as I wanted.

Hi, been a while since I posted last, and I seem to have gotten stupider, as I can't figure out what seems like a fairly easy problem. Working in FileMaker 9 (yes, I know, but still...) I have a table of companies, a table of attribute types (say A, B, C, and D) and a link table of the attributes for each company. I created a portal that will display the attributes for a company, and the user can add a new attribute by clicking on the first field in a new portal row, then selecting the attribute type from a popup menu. This is all straightforward, but I'm trying to restrict the values displayed in the popup menu so that it will only show those attributes that have not already been assigned to that company. In other words, company XYZ has no attributes, user clicks on the first field in the portal, and sees A, B, C, and D as options. He selects option C, and enters some related info. Then he goes to the next portal row, clicks the popup menu, and it displays only A, B, and D, since C is already added. Selecting A means that the next row will only allow B and C, and so on until all attributes are assigned, at which point the popup menu doesn't provide any values. I want this to happen without the user having to leave and re-enter the record, and without using any scripting. This seems like it should just be a matter of a few relationships and a clever value list, but I'm having trouble getting it to work. Am I daft?

When this happens to a site, it's quite often because of malware hidden in a rotating advertisement, rather than an actual hijack of the site itself. Malware distributors hijack a legitimate advertiser's system, or even purchase actual ads themselves, and then use these to distribute malware. Usually it's a Flash ad that exploits one of the gaping security holes that have been found in Adobe Flash over the past few months, though it can also use Javascript to open a hidden frame that opens a malicious PDF file. This can and will happen to pretty much any site that has advertising. Ironically, these malware ads are sometimes published by Google themselves.

Whenever I try to run FMSADMIN, I am getting the error "Permission denied, please try again." I have double, triple, and quadruple checked the credentials. There is no possibility whatsoever of the username or password being wrong. I can log into the server admin console successfully with the same credentials, but they fail when I use them with FMSADMIN.

I think what you need to do is not start a schedule, but actually start a backup directly. When you tell fmsadmin to run a schedule, it just sends a message to the scheduler, which then launches a separate backup process. So it won't wait for the schedule to finish. The easiest way to do this would be to directly run the backup from within your script, rather than using the schedule. So do something like this instead: :FM_RUN_BACKUP %fm% backup FilenameToBeBackedup PathToBackup -options :FM_CLOSE_FILES %fm% CLOSE -y -m "The daily backup has finished. The system will close all files for the night in 30 minutes." -t 1800 :COMPRESS_BACKUP copy_backup_to_external.vbs

I don't think there's much else to be done, unless you got into heavy math. As I understand it, the sequence of permutations is really arbitrarily chosen for its ability to detect typos, and you could replace it with a different P table and it would still generate a checksum, but just not detect the same sorts of errors.

Well, I just ran "your" function through about half a million iterations, comparing it to a known reference file, and it appears to be working perfectly. Congratulations.

Harrumph...

This is terrific, thanks! I'm planning to post this on Brian Dunning's site, with your permission. True, that's one of the nice things about the algorithm, as long as the checksum is appended to the end of the number. I'm testing by comparing to thousands of checksums generated using a known-good implementation, and it's looking good so far!

Sure thing... It's called the Verhoeff algorithm, and there are several good descriptions of it available online. I started with the wikipedia entry, and then followed some of the links at the bottom of that page for source code and implementation examples. http://en.wikipedia.org/wiki/Verhoeff_algorithm

A bit more information... I've done some testing of my script against some presumably reliable sources, such as the CPAN implementation in Perl, and some reference tables, and the results look good. The vCalcsum function I created in an attempt to reproduce this result is obviously broken, I just threw it together to have something in place I could experiment with. The Verify function is pretty much the same thing as the generating function, except it includes the check digit, and if the end result is 0, it's a valid check digit, otherwise it's not. The nice thing about this algorithm compared to others, like Luhn, etc., is that it will detect a single wrong digit, or any single transposed pair of digits, 100% of the time. It also detects a big percentage of other common errors, like if you enter 323 instead of 232, for example, and detects many phonetic errors, like if you say ninety, but someone hears it as nineteen.

oops, I thought I had posted the file, sorry. vcheck.zip