Client / Server design??

[DannA]

I am more familiar with Access...

Is there a way with FM to build a front-end that links to a back-end(that would have all my tables)

I want to be able to update my front-end design without changing the data in the back-end portion.

Thanks for the push in the right direction

--Dan

[Kurt Knippel]

Filemaker is not really designed with a "GUI Front-end" builder and a seperate "database" backend, but with an intergrated system.

Access is no different in this regard, although it did originally start as a backend to Visual Basic.

That not withstanding, Filemaker does have a true database server component, that is far superior to MS SQL Server in performance and stability.

Filemaker does support ODBC access into local or remote data sources (such as SQL Server or Oracle or any ODBC data source) so you can link to corporate databases.

If you truely NEED a seperated "front-end interface" from "back-end data" you can accomplish this in Filemaker, although most of the time the result is not worth the effort.

However it is NOT necessary to change your data structure just to make interface changes. It is hard for me to get more specific since I do not know what you are trying to accomplish.

[DannA]

Kurt,

If all is stored in one file, i am not sure how to make changes to the user interface and then update the "running" version without screwing up the "data tables" in the "running version".

I guess i'll need to learn more about FM,what's a good book to read?

--Dan

[Kurt Knippel]

There are 2 modes that I use when I am developing. I'll call them online and offline. Online is working directly with the live files, regardless of whether users are connected or not. Offline is working on seperate copies of the databases.

With the exception of a couple of functions (define fields, reset layout order, access privledges) you can do everything else while users are connected to and working with the databases. As long as you are the only user of a particular file, you can also define fields. So it is not necessary to work with offline copies.

Once the major development is complete and it is deployed in the enterprise, I do perhaps 75% of my work on the live databases.

However for major work or before the actual deployment, I will work on offline files, and then simply import the data out of the old files. Automated procedures for backup/restore can be built if you wanna make this a bit easier.

My point? It is not necessary to work offline, this will be a choice that you can make if it is a necessity. However working online will be acceptable for the majority of your development efforts, especially those that do not involve data structure changes.

[DannA]

Thanks, for the help...

--Dan

[Rigsby]

Take care when working online! Changing layouts “live” can not only confuse other users who then get screen re-draws changing the way a layout looks, but if scripts are in use at the time you change a layout, and the past or copy or cut commands are used and you remove fields, things can get a bit scary! -)

I try to only work on NEW scripts when working online. A good working system is as follows:

Make sure that every file in a solution has a calculating field that auto enters the modification date of a record.

Make copies of files and work on them offline. Use the modification date to then find changed files at a later date and import them into your improved files. With a self relationship, the old copies of these records are easy to find and delete.

Rigsby

[Anatoli]

CaptCurt,

RE: "That not withstanding, Filemaker does have a true database server component, that is far superior to MS SQL Server in performance and stability."

I like that very much! Did someone publish test about this? I'd like to have it Please!

Thank you!

[Kurt Knippel]

This is mainly my own experience working with both systems. I always found SQL server to be a real pain in the *** to setup and administer, and it continually had to be optimized and fiddled with. Plus it often drained the processing power of the machine it ran on to the point that they had to be restarted with sickening frequency.

This is not so with Filemaker Server. I have now 4 Filemaker Servers running at one client which basically run 24/7 completely unattended. In fact they are headless servers. They have neither a monitor nor a keyboard/mouse attached to them. Usually I only need to work with them when I want to move databases around.

Now of course Filemaker Server does not have 90% of the tuning capabilities of SQL Server, but this could be a big part of the performance/stability that it exhibits.

I'll ask around as it is possible that someone may have run some performance comparisons.

[Anatoli]

The same here If we need to restart server, it is not because of FM problem. It is running 24/7, doing auto backups just in case, because it never had problems or problems and it is cheap and fast.

[Jodin]

seems to me that comparing SQL Server to FM Server is like comparing apples to .... applesauce. They both *do* the same thing but beyond that there is little comparison. SQL Server will run circles around FMServer as far as raw database serving. Plus you can have interfaces built in all kinds of things (including FM client) that can use SQL Server as the backend.

That said, I love FM Server and being that it is our only choice for serving FM files I use it all the time. But I don't really see a situation where you would have to decide between SQL Server *OR* FM Server. If you are building the solution in FM then you use FM Server, if you are building it in something else (VB, ASP, etc.) then you couldn't use FM Server if you wanted to.

Anyway, back to our regularly scheduled program.

jodin

[Kurt Knippel]

Well not really true at all, but we can both argue our points until we are blue in the face.

I have worked with MS SQL Server, Oracle and FM Server as well as a bunch of desktop databases.

Although it is more fair to compare SQL Server to Oracle since they are much closer in function than they are to FM Server. However in purpose all of them are nearly identical. They are all database servers and if you had nothing and were evaluating option, comparing them is perfectly acceptable.

As to SQL Server running circles around FM Server, I will beg to differ. From all of my experience FM Server is worlds better than SQL Server in actual processing throughput. Yes SQL Server has the potential to be more powerful, but it takes SQL Server experienced DBA weeks to maximize the performance of SQL Server and at no small expense, whereas FM Server is quite powerful right out of the box.

Again this is based upon my experience working with all of them, including advising companies on making choices between them. Sometimes I have recommeded Oracle (blows them all away), sometimes Filemaker Server and as a last resort SQL Server.

Obviously if the solution requires either Oracle or SQL Server, then I would not recommend Filemaker Server, I would almost always recommend Oracle or Sybase or Borland's engine or MySQL, etc.

[Jodin]

This pains me to say this (being a fellow who bleeds 7 colors) but SQL Server is a fine product, possibly one of M$'s best. In my experience it is fast and stable right out of the box, and it only needs tuning if you plan to throw more data at it than you would ever use FM for anyway. It can run with Oracle's finest on the low to medium -end hardware and M$ provides a lot of halfway decent development tools.

I still don't agree that it's something that can really be compared.... the decision of which server is made by what your front end is built in. If your interface & logic is FM then of course you'd use FMServer. If your interface is anything else I can see no reason (or even way) to use FM Server. If they have nothing existing then you have to compare client to client features in my opinion - what functionality do they need and would the best solution be to develop in FM, Access, ASP, VB, 4D, etc.

Remember too that FM Server still passes a bunch of the processing off to the client. It's basically a large RAM cache for the FM Files. I love FM Server but it's a 800k program that backs up your files and lets you share them about 50x faster. Beyond that it's really not a DB server as such, at least not in the way I learned about such things.

Even FileMaker will tell you - if you plan on storing tons of data look into dumping it off to a professional-level DBMS, like SQL Server, Oracle, or MySQL. In my experience a well-designed FM system maxes out at 2-3 million records... even a moderately configured SQL Server would handle that in a heartbeat.

On a related note, anyone here have any experience with FrontBase?

jodin