Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Developer 7 or Server for a web based display proj


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

Recommended Posts

Posted

Thanks in advance for any help from a NEW FileMaker User!

I was tasked with setting up a 50 screen display system - sort of like an airport's Arrival/Departure info screen. The info to be displayed changes daily and there must be site-specific info on each of the 50 displays. I was given FileMaker 7 Developer to work with. Aditionally, I have the requirement of accessing the database from each site using a Web Browser, WITHOUT user intervention.

I'm not sure at this point that FM 7 Developer will do the job. I have 2 main problems... I must know what info to "pass" to each display (really a PC and a display). I have tried using Get(SystemIPAddress) from a startup script, and attaching to the database using InternetExplorer with Instant Web Publishing enabled, but I get the IP of the HOST, not the remote (Client).

Second, if I'm ever able to know what IP is accessing the database (which will enable me to FIND the pertinent info) Web Publishing will only let me display 5 records at a time when viewing a layout in list mode, and I can't SCROLL WINDOW (the script command doesn't work with web publishing).

From my readings it looks like I need FM Server Advanced just to serve the database to more than 5 clients, BUT will it allow me to do what I need?

Any suggestions are appreciated !!

Posted

It sounds like you want to use server advanced with 50 client seats. In this case, using the Get(SystemIPAddress) function will return the IP address of the FMP client machine at each of your 50 displays. You can use a calculation field with this function to create relationships that will cause the correct data to be displayed depending on the IP address. As you have seen, this function does not evaluate for web browser clients, but if you want a web user to be able to see data for a specific display, just use a similar filter as that for the 50 displays but put the IP address in a global field (maybe with a popup list to choose the display) and create a relationship with that global field.

One way around the 5 record limit in Instant web publishing is to use a portal to display records instead of list view. The other way, which is available if you use server advanced, is to use custom web publishing.

If you plan to just use developer to create runtimes for each of your 50 displays you have to remember that runtimes aren't networkable. You won't be able to pull data from each display to the web without user intervention (export records to HTML table, upload to a web server etc.) Unless you use a plugin like abstrakt shell. Shell allows you to move filemaker data into and out of command-line based programs on windows or mac. Combining this free plugin with a script scheduling plugin would allow you to sync data from another source and out to a web server on a regular basis.

It's not really good for a realtime setup, but if the data only changes once a day, and the displays are read-only (users don't make changes to the data from the display) it would work.

Posted

Reed, Thank you for your response. I'm very interested in your statement ..." but if you want a web user to be able to see data for a specific display, just use a similar filter as that for the 50 displays but put the IP address in a global field (maybe with a popup list to choose the display) and create a relationship with that global field."

I don't understand what you mean by this, especially with the requirement that this "display system" only DISPLAYS information - NO user intervention or interaction will be allowed.

Do you see my problem? If the web-user display can't "send" its IP address via a global field, I'll be forced to use 50 FileMaker Pro clients.

Thanks for the help!

Posted

Do you want to have all 50 displays networked to a central server? If so, you have two choices, Each display will have a filemaker pro license, or each display will be a web browser. If you want to use a web based display system that automatically refreshes without user intervention, then you'll likely have to use server advanced and custom web publishing.

I'm not quite sure what you want the web user to be able to do.... Do you want to be able to change the data on each display via the web, or just see what is on each display?

The bottom line is if you want a networked setup that uses filemaker on the 50 displays and the data is hosted from a central location, you need filemaker server and 50 licenses for filemaker clients. If you need this and web connectivity, you need filemaker server advanced and 50 client licenses.

If you want to use FM Developer to make runtimes, they will not be accessible via direct filemaker networking or web publishing. The only way to get data in or out of those systems would be via data import/export as I mentioned before. One way to go about this would be to have a central filemaker pro computer that holds all of the records, where each record has a field that says which display it would show on, export 50 different files with 50 different names, identifying which display they belong to. These files would be stored on a file server accessible from each of the displays. The runtimes would be set up to import the appropriate data file at set intervals (A plugin is required for this) In this way you would be able to update the data on each display daily (or hourly, or whatever time you want)

BUT.... the runtime apps would not be directly accesible from the web, since runtime apps don't have the web publishing features of filemaker. You would only be able to tell what data was on each display by connecting to the copy of filemaker pro that created the 50 exported files, and querying for the appropriate records. It would be difficult, however to use a web browser in this way to cause the data on a particular display to be changed.

Let me know if this helps, and if it doesn't maybe I need more details on exactly what capabilities are needed both on the display end and on the web end.

Dana

Posted

Dana, Again, thank you for responding. My "display system" WILL have all the 50 PCs generating the display screens networked to a central server. Management would GREATLY desire a web browser based solution because of cost and future modifications. We want the web "user" to do absolutely nothing! All we are aiming for is an information DISPLAY, but the information at each display will be different. This is because each display is in a physically different location, and different info is required for the "user" at each location.

If I read you correctly, it sounds like an "automatically" refreshing web browser based solution requires Server Advanced and Custom Web Publishing.

You explained a very workable runtime solution also (not easy, but workable)for which I also thank you.

Since I seek more detail, wouild you suggest I post on the Server forum? I'd like to know HOW Server would help me direct the info to the correct web browser based client.

Thank you so much for your time!

Posted

Since the IPaddress can't be used to identify a web user for the purposes of data display, you could create 50 different user accounts for each of the displays, and have the web browsers logged in to those accounts. The records to be displayed would have a field that identifies which account should display that record. You could (almost) do this with instant web publishing. Just create a layout with a portal to the display records, create an unstored calc field that =Get(AccountName) and filter your portal based on that field. The problem with IWP is that you can't add extra custom stuff to it like a meta refresh tag or a javascript that will autorefresh the page on a regular interval. It's either all instant or all custom on a page.

I did think of one possible way that this could work with IWP.... There should be a way to script windows (or mac) to cause the browser to quit and restart itself on a regular basis. If you just set the homepage on the browser to point to the page for your DB and save the account information in the browser, this could work. I'll look into this, since it might be something I could make use of also.

Whether you use IWP or CWP though, you'll definitely need server advanced, since FMP only allows 5 concurrent sessions. If you use IWP and server advanced, you'll be limited to 100 sessions. CWP without sessions could allow more scalability (esp. since you really don't need a persistent session for this application.)

Posted

Dana,

Your ideas sound quite interesting. Being very much a beginner with FileMaker, I have more questions... your statement "you could create 50 different user accounts for each of the displays, and have the web browsers logged in to those accounts." By this you mean 50 FileMaker accounts, not Network accounts, right? Then HOW do I have a browser log INTO an account? IF I'm using Web Publishing, don't I access my database by entering the IP address of the host machine on the browser address line? (I still need to get past the 'Select database' splash screen automatically)

Thank you for your persistence.

Posted

If you just copy the link from the 'Select database' splash screen for the database you want to use, and make that your home page, then that DB will come up, bypassing the IWP homepage. The problem I see with this is, You are still prompted for a username/password even if they are saved with the browser, so my idea about having a script that restarts the browser on a regular basis won't work with IWP, since someone would still have to press enter every day to get past the password dialog. The only way to not have a password dialog come up with web publishing is to use the guest account. But then there's no way to distinguish between computers, since none of the other Get() functions evaluate for web users.

Which leads back to CWP.... this is not something I'm experienced with, but I'd imagine that with the site assistant tool that comes with server advanced you could put together a page that shows the data you want, then just add a meta refresh tag or a javascript to the page to make it automatically refresh. This way you wouldn't have to worry about the password dialog to refresh the data since you wouldn't be restarting the browser.

  • 4 months later...
  • Newbies
Posted

With MAC OS, you can use the UNIX utility CURL to emulate a person entering anything you want. I other words, it acts like someone at that computer typing in the

password and UID, etc, and you will get a return from the server;

I was just granning the return string with applescript but I think you could open up a page with it.

The sequence is filemaker->calls an applescript-> calls a CURL command;

returned string is inserted in to FM.

This was used with a FM client not a web client, but curl is definitely accessible with a Mac system.

This topic is 7183 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.