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

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

Recommended Posts

Posted

The college I work for uses FileMaker exclusivly, and I am in charge of most of the Filemaker development for database work on campus, we are starting to expand into using more web databases, and at the same time some new work is being done on the College website as a whole. One of our Network Team members who is working closely with the Web developers is very anti-filemaker (primarily because he says that it is too limiting for web work, but since we have not used it in this way, I think his assumptions are a uninformed)

He prefers to use ASP or PHP, and says that FileMaker can't do the same things, Since I have not done extensive web work (in filemaker or in anything else) I really can't say this is true or false. Does having the database stored in Filemaker rather than in another format limit things as much as he says?

If not, can you all give me some examples of some nice websites run on FileMaker that I can show this with?

Posted

Well, first of all neither ASP nor PHP are databases. Filemaker is not a web scripting environment.

This is like saying that public transportation is too limiting, I prefer oranges. In reality they have almost nothing to do with each other.

Filemaker even has a PHP connector (although I do not know who make it) to allow access from PHP into Filemaker.

What he might mean is that CDML/Web Companion is more limited than ASP/PHP and this may or may not be the case depending upon what you want to accomplish. Lasso is probably closer in power to the PHP/MySQL combo.

Whenever I am presented with a situation like this I think about advantages, not disadvantages. Does Filemaker present any advantages to this web site? Will the Filemaker database and/or the data in them also be accessed by non-web user (via normal Filemaker Pro)? If the solution does not use any of the advantages that Filemaker provides, then I look at other engines, generally MySQL.

We (at FMForums.com) faced a similiar decision a couple of years ago, when we switched from the Perl based forums to the PHP/database driven one we have now. We thought about using Filemaker as the backend, or using Filemaker to run the whole thing. However it really came down to the fact that we were NOT using any of the advantages that Filemaker provides. So we went with MySQL, which is cheaper, faster and does not have any of the wasted advantages anyway.

Posted

That's how I felt as well, He seems to focus on ASP/PHP because he feels he can't retrieve the data from filemaker adequately since he can't use these tools, and since I have not done extensive work with Web companion or Lasso, I don't know how to respond that there are comparable features available when using FileMaker to store the information.

The main benefit we are looking towards is support, we have a good knowledge base on campus for FileMaker, but are encountering a wall between Web-based solutions, and Server based FileMaker databases, in that our Web team (due to this one person's leadership) wants nothing to do with FileMaker, but also doesn't want to support end users in the databases he has.

We don't plan on using FileMaker for all solutions, but this person implies that only the most basic web work can be done in FileMaker, and won't look at the benefits because all he is willing to look at is what he sees as deficiencies

Posted

RE: but this person implies that only the most basic web work can be done in FileMaker

What a stupid idiot it is!

FM is just database -- data container as all other databases. FM is faster in plain search over the web, than SQL like MySQL. In more complex queries MySQL is faster.

Now, what you can or cannot do depends on middleware.

This is my conclusion:

ASP = slow, no direct connection to FM

PHP = fast, free, connection to FM (and all other databases), I do not like the programming.

Lasso = fast, connection to FM (and all other databases) and I like the syntax debugger and programming.

HTH

Posted

If the new web projects are totally unrelated to existing databases, I'd let the developer work with the technology he prefers. If it does need to tie in to your current FileMaker base, then he should take a look at this: http://www.iviking.org/FX.php/ -- and he should look at Lasso, too. Just because he hasn't worked with it doesn't mean it should be rejected out of hand.

Posted

Howdy! Here's a breakdown as I see it. Folks here can correct me or help refine it but I hope it gives better understanding of how stuff works. I have minimal experience with some of these technologies, but here's my opinion for whatever it's worth...

"FileMaker" Web Solution (proprietory)

database = FileMaker

web server = FileMaker plug-in called Web Companion

cgi-scripting language = CDML (Claris Dynamic Markup Languange) which can be thought of somewhat as a FileMaker web language that works with HTML

AMP Web Solution (free)

database = mySQL

web server = Apache

cgi-scripting language = php ; it also works with html although it can also be by itself

I don't know enough about ASP but it's proprietory to Microsoft.

Depending upon your intended uses as Kurt et. al. point out (listen to them all), you do not have to use "just" FileMaker by itself although you can if you want to and your needs do not exceed its capability. For your particular situation, I would recommend you investigate using FileMaker as your database and using Apache and php for your web components. That way, you can continue using FileMaker as you always have while letting the web developers work with something SIMILAR to what they already know and trust. If you and your staff were going to do it yourselves, I would recommend Lasso since CDML was made by them anyway and is not limited like FMP out-of-the-box is.

I am in higher education, too, and we have mostly stuck with "just" FileMaker in my area's departments, but this year, we had to use a little JavaScript and php to get one of our FileMaker web solutions to work with our campus user authentication system. I feel we are moving in the FileMaker/Apache/PHP direction as we begin to outgrow FileMaker as a standalone. Apache is a robust web server. FMP's Web Companion is exactly that... a COMPANION to FileMaker to let you serve on the web but it was not designed to replace Apache or other web servers. FileMaker, Inc. has even said in its documentation often that it's focus is the client database, not the internet services aspect even though it does (thankfully!) do so.

I can teach end users how to use FileMaker in a day... making records, entering data, creating layouts, performing searches, etc. If you are using FileMaker as extensively as it sounds like, I would definitely explain to them how crucial FMP is to your function. I do not believe a front end web interface using Apache/php would be too much to ask and I don't think they would have too much trouble using FMP instead of mySQL. I cannot confirm this as we are only fledgling PHP/Apache users, but that's my 2 cents. Hope it helps!

--ST

Posted

With Lasso or PHP the web can be in some cases served only from MySQL and final result can be posted to FM databases after all possible checks and validations. That will bring an extra security layer into play.

RE: I don't know enough about ASP but it's proprietory to Microsoft.

Not fully, because there is some engine for ASP on Linux as well. But I guess that will still work the best with M$ technologies in background and ASP is slow.

PHP, MySQL and in some degree also FM are very crossplatform technologies. Right now I am firmly with Microsoft after I was disappointed with MacOS. But all my solutions can work with Mac X just after small changes. So if M$ will damage their own technology by stupid marketing or the complexity of their ever growing code or with security issues, I can move somewhere else.

I am usually involved just in database logic and web integration and I don't give penny for any OS. If the IT will switch focus to other platforms, hopefully my tools will work.

Posted

Thanks everyone, you all seem to be bringing many of the same things that I have pointed out to him, except for the fact that php can be used with FM, He pretty much just ignored that due to the need for purchasing additional software (you do need some sort of php connector don't you?)

I have done strictly FM work, and we are just now starting to develop a little on the web, at the same time the college has organized this web team to manage the college website, consisting of one Network tech (the guy I'm having problems with), one web developer, one PR person and a group of student workers. Currently they are working on developing standards (which is one of the reasons I can't give specifics on what we will be using this for because this will really apply to most anything. The Network guy does NOT want to handle database management at all, so any database content coming from anyone but that team is meant to be handled by the users (which in effect means we have to support it through the Help Desk and current Database management systems which only use FM. A large portion of the solutions are being used on campus directly through FM, and would probably continue to be.

The main purpose of my question here was since I haven't done much extensive work with FM and the web I really don't know of the limitations (if any) and this Network Tech insists that there are. I feel like it isn't a matter of filemaker's limitations, but since he doesn't know how to do it, he insists that we use something else. (BTW this person will probably be doing very little of the actual programming if any)

Posted

Limitations in FM -- non-existent security and poor security. And not everything on web is like in FM.

But if you use middleware like PHP or Lasso and store temporary results in MySQL, then you can build and secure anything.

  • Newbies
Posted

Think about what will work the most efficiently for the tasks that need to be accomplished by using the db solution. It is supposed to be a solution after all, not a choice simply for the sake of uniformity--that would be foolish to sacrifice performance and efficiency for that--especially since FM professionals should know how to transfer information between enterprise backend solutions and workgroup ones. So here

Posted

(Note: this is not in response to Garry)

"The college I work for uses FileMaker exclusivly..."

"The Network guy does NOT want to handle database management at all..."

Which will be the most cost effective to replace, FM or the Network guy? laugh.gif

Posted

I don't think I am getting my point across very well, I understand that FM is not the best choice for all website work, and I know that every solution is different. Most of what we are looking at using FileMaker for are applications where FileMaker is already being used, or would have all the capabilities needed. General comments this person has made about FileMaker's limitations are pretty much unchallenged, and while it is not this person's job to develop the solutions, he is holding us up from doing anything with FileMaker because of these "limitations". He can't be specific on what he feels can't be done in filemaker, but insists that it's too limited. (I am aware of the size limits, and this really isn't an issue since most of these applications will store fairly small amounts of data, in very simple data structure)

I basically am just wanting some examples of what limitations filemaker has, so that we can see if these limitations are going to be as big of problems as he says they are, or if this is just his personal dislike of filemaker.

All he as taken the time to look at from FileMaker is Instant web publishing, and we all know that is WAY too limiting, but he is using that to compair fm to what he has seen done on other websites, and assumes nothing more can be done.

Posted

So ask the guy to be specific. Then we can address the question specifically. Meanwhile: 1. call your FileMaker sales rep, he/she will be more than willing to help you prevail. 2. check out the FX.php link in my post above -- it's open source and free.

PS: jpb, great first post!

Posted

The only limitation I can think of is perhaps size and complexity of relationships. However, if the databases are already designed, developed and implemented these are not relevent limitations.

Your current databases can be developed into a web solution with no more effort than would be needed to develop an alternative solution.

I am available for consultancy on cost-benefit analysis for various IT plans.

www.clarsys.com.au

Good Luck.

Garry

p.s. If you could knock-up a couple of example CDML solutions you may gain a headstart on him.

Posted

OK, we have portal with all PR press releases from whole ITC industry in FM database. Names like Microsoft, Oracle, IBM, Sybase, Adobe, HP, Olympus, Dell etc.

On the same machine and the same FM engine is running Technical weekly magazine from Bertelsmann publishing house.

Served for press and public 3 and half years without problem. Reliable, cheap and fast.

Actually Sybase want us to use their SQL and want to give it to us free. Expensive to write and maintain.

$60 million US company I was with is taking orders both ways -- traditionally and from web. FM is the database.

You cannot get bigger names than that smile.gif

Posted

Hi, PB! Using Custom Web Publishing, you can do most basic functions with Web Companion as you can with FileMaker, but there are limitations and idiosyncracies. Here are some I have encountered and/or read about... I hope I don't make a mistake or mis-say something (but I'm sure folks will let us know!)

What limitations does FMP Web Companion have?

(1) reactive state - in order to get any data from the database whatsoever, you have to perform an action of some kind first (-find, -edit, -new, etc.) before showing any data, record lists, value lists, etc. For example, in a calendar system I'm making I must use long CDML links/urls to bring the user to my first page or use the equivalent form submittal or META refresh to do the same thing if I want to immediately display a list of the activities or events happening today.

(2) stability - some folks have had mysterious UNEXPECTEDLY QUIT problems anywhere from weekly to several times a day when they suddenly find they are not serving. There seem to be several factors involved and it affects both Windows and Macs, but there are also success stories where some folks have no trouble at all.

(3) security - out-of-the-box, you will probably have to use FMP's Web Security Database (or Access Privileges) but some say that this is not that secure. I have not had security problems with it but I did find it annoying that I could not specify field access by user this way. If you are working with confidential information, I would not recommend FMP unless you knew a lot about security and could properly check your systems.

(4) scripts - although you may be able to get your FMP scripts to work safely on the web, I hear it is not straight forward or simple but acheiveable by developer-level folks

(5) web services - developers who are familiar with Apache et al. will not be able to take advantage of many of the built-in or additional services (modules) that full web servers can do. You can choose Web Companion as your main web server, but your web developers will lose access to a lot of the tools and resources they are used to.

(6) load - I haven't seen hard figures for WC's performance, but I'd be surprised if it's anywhere in the same zip code as full web servers; I could be wrong but I would place it somewhere between a personal web server and a full web server

(7) support and distribution - this forum is great but documentation on how Web Companion works may be hard to find whereas info on servers like Apache are numerous with truckloads of experienced experts. If you outgrow FMP's limitations, you may want to ask CAN WE DO THIS LATER? Odds are the answer is NO with Web Companion whereas the answer is probably YES with Apache.

(8) cost - even with an educational discount, FMP-Unlimited is pricey. If you run many servers, that can add up fast whereas Apache is free.

Now, many of the things I mentioned above can be compensated for with additional products, and I'm sure there are other things I have not mentioned yet but these are the ones that come to mind off the top of my head, and it wasn't hard to come up with them.

If you want to web publish existing FMP databases using Custom Web Publishing, all it takes is some web design skill and a little coding experience. You should know HTML if you are serious and at least a little JavaScript seems to go into everything we do these days. Searching, creating, and editing records in a sequential db is easy. A related db w/portals ups the ante a little more. A complex solution w/many db's and scripts is a lot harder.

FILEMAKER WEB DB EXAMPLES WE HAVE DONE OR ARE IN THE PROCESS OF MAKING...

* Search engine for clubs and organizations contact/description info

* Web surveys and evaluation forms

* Volunteer opportunities post and community service agency listings

* Tracking system for each student to log community service performed (php & JS cookies for campus authentication system so we don't have to creat logins/passwords for everyone)

* Activities calendar for students, faculty, and staff to post events and programs they are sponsoring at the University

* Registration status / confirmation status for undergraduate orientation programs

* Internal db resources for staff

* Online sign-ups for campus activities and events

All of these are/were served on modest systems (300 MHz G3 Macs) and most of these from a single server. We use FileMaker Pro, Unlimited - educational version license & media only and until recently that's all. Our new community service tracking system required us to enable php on Mac OS X's apache. We are starting to look at Apache to serve all the static web pages and just using FMP for the db stuff. We are also looking into php more as it is a fully-functioal web scripting environment. If I had the money, I would probably go the Lasso route instead since it is more FMP-friendly and would not require us to re-code our web solutions. Check out FX as Fitch says... I believe it allows you to use both CDML and php together instead of one or the other.

Hope this helps at least a little. My fingers are starting to cramp!

--ST

Posted

Ummmm... I guess I should add that I was talking mostly about WEB COMPANION, not FILEMAKER. As folks have mentioned and pointed out, it is not really an issue of FILEMAKER being limited as the database, per se. I inferred that you were talking about using Custom Web Publishing with FileMaker Web Companion.

And don't get me wrong... I am a BIG fan of FMP and Web Companion. It's just a matter of purpose and usage. --ST

p.s. I forgot to add Anatoli's warning about needing Unlimited even if you use another web server to serve your FMP db's... I forget exactly but it's in the forums here somewhere.

Posted

RE: Anatoli's warning

I don't have a warning smile.gif Just I am mentioning frequently the FMI licensing policy. If it is on web with middleware it must be Unlimited. PHP or Lasso -- no difference in licensing.

Posted

Also depends on version. FMPro 4.0 does not have an Unlimited edition. It also does not have InlineAction or multiple Tokens.

Re: (1) reactive state - in order to get any data from the database whatsoever, you have to perform an action of some kind first ... (Steve)

I think Steve might be saying that the web is stateless. Because of this a browser client is not in constant touch with the db file(s) as a peer-to-peer client is. This is not normally a great problem.

Posted

That's the problem, he says he doesn't know enough about it to be more specific, but still insists that it is too limiting. That's why I came here and brought it up, I thought if some of you could give me 1. some examples of good websites to show him, and 2. a little insite into what limitations you have run into so that we can take an honest look at this rather than just running from people's personal likes and dislikes.

Posted

"he says he doesn't know enough about it to be more specific, but still insists that it is too limiting."

Using data already in existing FM databases does not seem to me to be limiting. How does this person plan to make this data available to web clients? Magic?

Instead of arguing the pros and cons of FM with a person who has no knowledge of FM, have this person explain their solution to serving already existing data over the www in a way which is both dynamic and without limitation. I, along with several others, would like to know.

From what you have written the limitations appear to be this person's lack of knowledge combined with a reluctance to take on something which will require the effort of learning on his part. It appears that this person is willing to close the door to an opportunity to learn (to enhance his own resume) while getting paid.

I go back to my original question to you, "Which will be the most cost effective to replace, FM or the Network guy?"

Posted

Current FMI licence is clear:

SPECIAL TERMS FOR FILEMAKER PRO ONLY: If you have licensed the standard version of FileMaker Pro, when deploying FileMaker Pro for hosting non-FileMaker Pro clients, you are permitted to host up to but not more than ten (10) guests (e.g., IP addresses via the Web Companion) or other API connections (e.g. ODBC, JDBC, Apple Events or ActiveX) on a rolling twelve (12) hour schedule. You are further prohibited from using the standard version of FileMaker Pro with any middleware, application server, CGI, or other software or technology that allows more than a single client to access any FileMaker Pro database.

SPECIAL TERMS FOR FILEMAKER PRO UNLIMITED ONLY: If you have licensed the FileMaker Pro Unlimited version, there is no license limitation on the number of guests accessing FileMaker Pro via the Web Companion (e.g., IP addresses) or other API connections (e.g. ODBC, JDBC, Apple Events or ActiveX) on an intranet or the Internet. You may also use FileMaker Pro Unlimited with middleware, application server, CGI, or other software or technology when hosting a FileMaker Pro database. The FileMaker Web Server Connector included with the Software may not be used with configurations that include standard FileMaker Pro.

What part do you not understand?

Posted

Hey I just saw the second page.

We are working with Unlimited and Web Companion. We have a full site license (Boxed Set) so we can install as many servers as needed with only the added hardware cost.

I just don't have the html experience to really blow this guy away with an amazing example, (which is why I came here to see if you all had some good sites I could point him to that show off FileMaker's ability to support professional looking cutting edge websites.

As for the list of limitations, that Steve T. gave, this is great, but I have a few questions on some of them:

(1) reactive state - I assumed this was the case with other solutions as well, is it more complicated with FM than other systems?

(3) security - We are familiar with this, most of what we would be putting out there would not be great security problems, so this is noted, but probably not a big issue for us.

(5) web services - We have a good web server now, the web companion would be an additional server that would handle just the FileMaker resouces. We assumed this would be the best solution since a good portion of the College's web presence would not be database driven.

(6) load - Since this would be not be responsible for the bulk of the College's website, I don't think the load will be that great, but it's good to know we may come up against this in the future.

(8) cost - Since we already have a site license this is not a limitation because we can install as many additional copies of unlimited as we need with no additional cost.

Posted

From my experience I would like to reiterate, and add a couple more of the limitations of Filemaker.

1. Complex relationships can be difficult to construct.

2. Complex relationships can cause speed problems.

3. Post-search and pre-insertion data manipulation can be a limitation. This is usually achieved in the browser by Javascript, or middleware such as PHP.

4. Security has some limitations without the use of middleware.

This is a good exercise to go through for all of us.

Good Luck.

Garry

p.s. Anatoli, I know which part you do not understand!

Posted

So your discussions run along the lines of "It's too limited!" "Is not!" "Is too!" Is not!"...?

Again I say, the onus is on him to specify:

1. exactly what the @#$! does he think the problem is with FileMaker and;

2. how then does he propose to leverage your existing databases?

Here's are some sample sites running on FileMaker Pro:

Database Pros

Webko's FileMaker FAQ

Blueworld List Search

Posted

The relationship limitations will be of no significance if the data is being served striaght from a db file without relationships. Serving data straight from a couple of db files is usually no problem with InlineActions. Load should not be a problem.

If the data which is to be served is for public consumption (not priviledged information like SSN's or CC no's), then security is not really an issue. After all, reading the available data through the site design generally is a lot easier than making sense of the same data viewed through a crack.

If the public is not allowed to create or edit records, there is even less reason to be concerned about security.

I agree with Fitch. grin.gif

Posted

Apple, Inc used to run its entire site off of Filemaker Pro and WebCompanion. However the needs of thier specific situation as well as the development of WebObjects caused them to move to that platform.

Posted

Hi, PB! Except for you, everyone who's particpated in this discussion so far has more posts than I, and probably more knowledge/skill/experience as well, but I tried to list specific issues to help draw a clearer picture for you and those who cared to comment/correct me. Kinda along the lines of what Fitch was saying, though, if you were to give some examples of some of the things you'd like to publish or some of the things that you campus nemisis says FMP cannot do, several folks here would be better able to assess the limitations with respect to the projects.

THEORETICAL EXAMPLE:

"We have an enrollment system for 8000 students that invovles 5 related db's and we would like to create a web-based course sign-up system which needs to track student enrollment requests and matches courses with students then rolls-over filled classes with their next best choices, etc."

If you told us that you were told that FMP cannot do this, a number of folks would be able to say YES, THAT'S TRUE, or NO, THAT IS NOT TRUE, or YOU CAN DO IT, BUT YOU NEED, X Y Z...

My guess is that you can do most everything you need w/FileMaker and Web Companion and/or maybe some extras.

--ST

P.S. Thanx for the Apple tidbit, Kurt! I hadn't known that. Thanx for the examples, Fitch! (One of these days I'll post our solutions for people to peek at but we're kinda running fast and loose right now and I'd like to double-check our security before throwing stuff out for the FMP-wise to see. That's why I just described them.)

Posted

Fitch said:

So your discussions run along the lines of "It's too limited!" "Is not!" "Is too!" Is not!"...?

Again I say, the onus is on him to specify:

1. exactly what the @#$! does he think the problem is with FileMaker and;

2. how then does he propose to leverage your existing databases?

Here's are some sample sites running on FileMaker Pro:

Database Pros

Webko's FileMaker FAQ

Blueworld List Search

I do agree, but those examples are not the best.

Database Pros and Webko's are without security and anyone can hack them

IMHO BlueWorld is MySQL (LassoMySQL) powered.

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