Jump to content

This topic is 7455 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I have a maddening problem with a simple CDML web application that displays images out of FileMaker. The nutshell is, it works fine when the server is running on a Mac with FileMaker Developer 6, but the images are not served when the application is moved to Windows Server 2003 running FileMaker Unlimited 6.

The basic architecture of the system is, the FM databases are hosted on a FileMaker Server system (Windows), clients connect to the FM Server to use the FileMaker-based application. A FileMaker Unlimited machine *also* connects to the same FM Server, and provides service for the web side of the application.

The web app is pretty simple: a search form, search results list, and item detail. The search results includes a single thumbnail image for each hit in the list. The item detail shows up to 10 images, full-size and thumbnails.

The images are added to the database by the end users on the client systems. The images are added by reference, and are stored on a local file server. The FMU has access to the file server, and is able to "see" the images on it. That is, layouts that include the images *do* display those images.

The problem comes when someone uses the web app. The search results page shows the missing image icon for each of the results, instead of the graphic. When you drill down to the detail, all 10 images show missing graphics. FileMaker Unlimited's Web Companion logs the error like so:

192.168.1.5 - - [12/Aug/2004:11:08:41 -0700]

"GET /FMPro?-db=gma%5finventory.fp5&key=41721&-img HTTP/1.1" 404 16

I.e., Web Companion cannot find the resource specified in the URL.

The CDML to display the image is very simple:

[FMP-RECORD] 

[...]

<img src="[FMP-IMAGE: ec_photo_thumb_01]" alt="Photo Unavailable" width="75" border="0">

[...]

[/FMP-RECORD]




When run, each record produces a line that looks something like:




<img src="FMPro?-db=gma%5finventory.fp5&key=39863&-img" alt="Photo Unavailable" width="75" border="0">

The problem is that this all works fine when I'm running the system on my laptop, accessing the databases locally or on our development server (both Macs). However, when the system is deployed to the client's systems (all Windows), the HTML works fine, and the application drives as you expect...except no images.

Anyone encountered something like this before? Ideas for solutions, or even how to isolate the problem?

Note that I know that the better way to do this would be to store the images' URLs, and have those point to statically-served graphics from a regular web server, rather than asking FileMaker to serve them. For a variety of reasons, the client wants to do it this way...

Posted

Re: The images are added by reference, and are stored on a local file server...

Have the images actually moved to the other server with the database?

Is the relative path the same on both computers (maybe it is looking for an absolute path)?

That is all I can think of at the moment.

Good Luck.

Garry

Posted

Have the images actually moved to the other server with the database?

Is the relative path the same on both computers (maybe it is looking for an absolute path)?

Well, the images are stored as external references to files that are located on a file server, to which both the Unlimited and the client systems have equal access. And -- importantly -- the images *display* on the screen on both systems, when you are viewing the same FileMaker layout in either. In other words, FileMaker itself can *definitely* find the images, on either system. It's the Web Companion that has difficulty finding the images when it comes time to serve them.

Now, the image references are absolute references, e.g.:

ServermacFM_images_system1104306306-004DSC02677.JPG (works)

ServermacFM_images_system1104306306-006DSC00130.JPG (works)

ServerMacFM_images_system1104991991-073DSC06200.JPG (doesn't work)

SERVERMacFM_images_system1104991991-076DSC06182.JPG (works)

(These paths are stored in a separate field, and are calculated by the import script. I don't know how to look at the actual/internal reference that the container field stores, is there a way to look at that?)

Now, looking at the paths, there are some obvious capitalization differences, but it's completely inconsistent (I've looked at dozens), there is no way to tell which references work or don't work just by looking at the path. And are Windows network paths case sensitive, anyway?

I am kind of wondering if FileMaker's use of references for internal display use one code path, that is not case sensitive, while the Web Companion uses a different set of code to get images to serve them up, and that code *is* case sensitive.

But if that was the case, you ought to see predictable missing images based on the case of the paths, and I'm most definitely not seeing that...

Posted

Hi, if you are serving images through a web page, it's much easier to do it purely through HTML, especially if you use WSC:

<img src="[FMP-Field:theImageLink]" alt="Photo Unavailable" width="75" border="0">

where "theImageLink" field just stores the path as an HTML link. If the image is on a different server to the database, you need to specify an absolute url (http:// etc), if not just relative path.

Container fields are bad news for web publishing!

regards, jeff

Posted

Hi, if you are serving images through a web page, it's much easier to do it purely through HTML, especially if you use WSC:

Yes, I understand this technique, quite well. As I wrote in my initial post, for a variety of reasons, the client wants to do it the way I've described. I've tried persuading them otherwise, but their reasons are not horrible, and so we're using container fields and the WSC.

This topic is 7455 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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