Archive for the ‘FileMaker’ Category.

FileMaker Server 12 Plugins

tl;dr: Plug-in developers can now update their plug-ins to run in 64 bit mode.
There’s an undocumented change to how the Web Publishing Engine runs that affects where to install plug-ins to be run by CWP.

A few weeks ago FMI released the FMS 12 v2 update, adding support for 64 bit plugins used by CWP solutions. FMI also released a new software developer’s kit (SDK) for plug-in developers. Until this SDK, there was no way for plug-in devs to update their plug-ins to run in 64 bit mode. So some FMS 12 plug-ins (possibly, all, I’m not sure) could, until this update, only work in 32-bit mode. Which was okay for most purposes, but the Web Publishing Engine (WPE) runs in 64 bit (on a machine running in 64 bit mode…you could run your 64 bit machine in 32 bit mode).

So far, I haven’t seen any release of an updated plug-ins but I’ve read or communicated with several devs who are actively working on updates: Goya, Troi, 360Works, and 24U. I’m assuming most of the top-level plug-in devs are on the ball.

There is one poorly documented change that should be noted. It’s documented a pdf in the new plug-in SDK and nowhere else that I can see.

There is now a new folderpath to install plugins to be use by Custom Web Publishing (CWP). Instant Web Publishing (IWP) is the same filepath as before (/publishingengine/wpc/Plugins), but CWP plugins now go into (…/publishingengine/cwpc/Plugins).

This change is not reflected in an updated FMS document (otherwise a superb pdf). It’s in a pdf that comes with the plug-in SDK. When called by CWP, the function Get ( FileMakerPath ) also returns a /cwpc/ path.

Thanks to Nick Orr at Goya and Diana Budding at Troi for being patient with my questions and to Obinna Oparah at 360Works for a couple informative posts on FM Forums.

Make a new plan, Stan.

or even use an old one… just HAVE a plan, and STICK to it.
A few thoughts for the next time we make a brand new database:
We should set some strict naming and formatting conventions so that all the names used for tables, field, layouts and scripts use the same rules, allowing us to construct references based on variables and knowledge of our naming conventions. I suppose there still remains the problem of what happens if we change some names… but maybe we could use one login to set up names of stuff and other admin logins to do all other work – and somehow disable the permission to rename stuff… ? I don’t know. It was a thought inspired by what I’ve been working on recently. It seems that a lot of what I’ve been doing the past few weeks has involved going through several instances of parts of the database that are built SIMILARLY but not consistently, and therefore I have had to do a lot of double-checks and fixes. We might save ourselves some time if we structure things a little more strictly from the start and try not the make changes to our naming conventions part way through the game. Part of the challenge here is that there are several of us working on the database and we don’t have a central reference for the way we are going to do things. I suppose that might be a good first layout to make – a reference with naming conventions and font choices, etc. David has talked about that. It’s a good idea… but it’s less practical to implement half-way through creating the database than it is at the very start.

A Solution So Simple It Could Never Work…

Again, working on the EasyBilling database on a Mac running 10.4, Filemaker Pro v. 5.5…

This time, when our client tried to create a new patient, he got an error message, a document navigation window and then a blank record where he was unable to enter a patient account number.
I watched him go through the fruitless motions of trying to create a new patient and then repeated the process myself, except when it lead me to the document navigation window to locate the document that the database claimed it could not find, I took a stab at finding it. Problem solved!

That is, until you close the database and reopen it – then it no longer knows where it’s files are. After trying to “teach” this database where its own corresponding file was located (by locating the file for it several times in several different ways), I thought to myself, “Fine, database. Obviously, I cannot teach you to fish. I suppose I’ll just have to bring you a pile of permafish so you’ll never go hungry again.” The file that it could not find was in a folder that enclosed the folder that the main database file was in. Does that make sense? Probably not.

Explanation: First off, Filemaker 5.5 is before you could have more than one table in a single file (or maybe Filemaker 5.5 could handle that, but this vertical market billing solution was designed in a version of Filemaker that separates each table into its own file) – so each table in this billing solution is its own file. That’s cool, until one of it’s files is moved – and then it freaks out (understandably – I would freak out if you moved my arm to a separate location!). You see, when we moved these files from the ancient computer to the antique computer a few weeks ago, they somehow came to be in a bit of disarray (I guess…). The EASYBILL.FP5 file was in a folder called EASY BILLING 3.5.7, in which there was another folder called EASY BILLING 3.5.7 which contained the rest of the database files. Which means the main database file was looking for its arm inside its house (folder), when really the arm was sitting just outside the house. You could point it to the right place, but as soon as you closed the database it would forget where you had told it to find its arm.

So… after the database proved itself dumb, I (figuring it would never work, that the solution could not POSSIBLY be this simple, but having no other ideas left to try) moved a copy of the EASYBILL.FP5 file into the same folder as the rest of the database files. And…. (drum-roll, please) VOILA! Magic! I restarted the computer, reopened the main file, clicked on the create new patient button and the database was able to find its arm / pile of permafish – all by itself – no learning necessary! Phew.

Installing Filemaker 5.5 on OS X (v. 10.4.11) and working around unreliable printers when accuracy of alignment is of ultimate importance

We recently had to install Filemaker 5.5 on an iMac running 10.4.11. The objective was to move an old vertical-market billing solution (EasyBilling or something) database originally developed in Filemaker from a mac running OS 9 Classic to the newer machine (still quite old).

Unfortunately, at least for the copy of Filemaker 5.5 that we had, it was necessary to install Filemaker 5 first. Filemaker 5 only runs in the OS 9 Classic environment, but luckily OS 10.4.11 has a Classic simulator which allows you to run programs that will only work in OS 9.

After installing Filemaker 5, we went to install Filemaker 5.5. Filemaker 5.5 supports OS 10, but since the database that we need has been running on FM 5.5 on the OS 9 machine, we thought it’d be best to keep the changes minimal and install Filemaker 5.5 to run in the OS 9 environment on the newer computer (FM 5.5 gives you the option when installing). All seemed well, FM 5.5 installed, database moved over to new computer, database appeared to be working, but the alignment with the new printer to print onto very specific insurance forms was off.

When I initially looked at the database, I thought I was out of luck for fixing the forms. Since it was originally built as an independent vertical market solution, the end user was locked out of nearly everything. Also, since it was an .fm5 file, each table was it’s own file. This turned out to be my way in, because the “Forms” file was the only one where Layout Mode was enabled. Once I found that, I was able to nudge the fields on one of the form-printing layouts and got it to print acceptably.

Next problem, not realized for a few days, was that any data entry into the database on the new machine, running in Classic mode, was wonky. When you typed, some letters and numbers would press themselves five or six times in a row. It was clunky, unpredictable and uncontrollable. It seemed like a keyboard problem, but after switching keyboards and restarting the computer and installing a fresh version of the database and testing the typing capabilities in other programs (both those running in OS 10 and in OS 9) and even creating a new database in FM 5.5, the problem proved itself to be related to FM 5.5 running in the Classic environment.

So….. we uninstalled and removed all things Filemaker from the new computer and started afresh. After installing FM 5, we installed FM 5.5, but this time chose to have it run in the normal OS 10 environment. Put a fresh copy of the billing database on and viola! – problems solved. I readjusted the form layout and had it printing adequately. At first the invoice numbers were not auto-entering as they should be, but putting a fresh version of the database on the machine yet again seemed to fix that. (We couldn’t do much else as we had no access to scripts or the table structure itself.)

Final problem, again realized another day later – while the printer would print the form correctly SOMETIMES, it was not incredibly reliable. This was a problem with the printer, but not one that we knew how to fix or control – just a shitty printer was the root of the problem. Since the printer seemed to err towards printing the numbers slightly above the box they needed to be in, I moved the numbers down some on the layout – and then the printer cut off the bottom half of the numbers! (much hair tearing ensued here) Finally, after quite a few trial and error prints and thoughts of just getting the client a newer printer or resorting to hand-writing the numbers in the correct boxes, I realized that the printer printed much more accurately at the top of the page (the part it prints first). So, as my one genius move of the week, I went into the form layout yet again in filemaker and GROUPED all the fields together (important or it won’t work) and rotated them as a group – twice, so that all the fields were upside-down. I then ungrouped them and made some minor adjustments, fed the forms into the printer backwards, and VOILA! numbers in the correct boxes. I printed several copies and each worked quite well. SOLVED!!! … that is, at least until the client returns from vacation and unearths more problems for us to work on.

A Very FileMaker Day

Today was a very FileMaker day.

I drove to Albuquerque to take the FileMaker certification exam.  I have been certified in FMP 9 since 2008, so I decided to catch myself up and test for both FMP 10 and FMP 11 in one go.  It was a grueling four hours…and I passed!

The FileMaker Pro Users Group meeting was that night and we had special guests…three staffers from FileMaker Inc.

I left the testing site to show up late to meet the FMI and the NM FMPUG crews at the Elephant Bar a couple blocks away from the Albuquerque Public Schools building.

Karen Weaver, Stephen Clark, Don Clark were there from the FMPUG group. Glen Suarez, Stephen Gallagher, and Alexi Folger from FMI (which graciously paid the tab for the table).

Glen, the regional account manager, started with his standard opening presentation and then Alexi, the engineer, took over to discuss FMGo. She’s one smart lady.

The three then took questions from the crowd and gave away some schwag.