Filemaker has a long way to go

[Zahary]

Filemaker still requires you to link layouts to tables to access them. Example: Set Field( Table1::field, Table2::field) will always copy a blank value regardless of the field's content.

Separation of data and design with a query language will always put Filemaker in a class with a standard spreadsheet program.

I use Filemaker everyday to create elaborate SQL based front ends which make up for the endless relational deficiencies of Filemaker. Filemaker is a great program if used for what it can do. Calling it a relational database is just wrong.

[Kurt Knippel]

Zahary, I think that you are underestimating Filemaker and just plain wrong in some things. I am not sure what specific relational deficiencies you think exist, but I find that it is just that Filemaker implements them differently than a SQL based tool.

In your example, it will only copy a blank value when there is no valid relationship or when there are no related records to draw the value from.

[jpd33]

Zahary, I really do not think you are trying to do a relational function. Maybe your just trying to do a glorified copy and paste function.

Could you better explain the process you are performing?

[Zahary]

>>it will only copy a blank value when there is no valid relationship or when there are no related records to draw the value from<<

You should be able to reference fields independently of the layouts. The layout defines the starting relational table. For example: Lets have three tables, lefttable, manytomanytable, and righttable. The lefttable is assigned to the layout. If you were to relate the PK lefttable to the FK manytomanytable, then the FK manytomanytable to the PK righttable, you could not drop the righttable field on the layout, even in a portal since you could possibly retrieve many records.

In my case, I load unqualified data from a foreign source in to a filemaker input table. Then I clear an address table of its records. I want to step through the input table processing records which span more than one row and insert the processed record into the address table. The only way I know of doing this is process the record into global values, switch the layout from the input layout to the address layout (since layouts are used to access tables), then insert the global values in to the address table.

My gripe is you can select fields from one table and insert them in to another table in a relational database usually in a single command. In Filemaker, you have to copy the fields in to global values then insert the global values in to the table. It is not always true that your tables are related at all, as in the raw data validated and copied in to an address table above.

Now if there is a good way to do this, I am excited to learn new things.

Z

[-Queue-]

Would it be possible for you to import from the first table to the second?

[Kurt Knippel]

Zahary said:

You should be able to reference fields independently of the layouts. The layout defines the starting relational table. For example: Lets have three tables, lefttable, manytomanytable, and righttable. The lefttable is assigned to the layout. If you were to relate the PK lefttable to the FK manytomanytable, then the FK manytomanytable to the PK righttable, you could not drop the righttable field on the layout, even in a portal since you could possibly retrieve many records.

I am unsure of any RDBMS which handles many-to-many joins any better. Exactly what data are you expecting Filemaker to present?

For a better example lets say that you have Students and Classrooms and maybe you have a many-to-many join table called Courses. You are looking at a layout connected to the Student table and drag the Classrooms::RoomNumber field over. What data will it show? What is the relationship between a Student and a Classroom? How does Filemaker know?

Now if you had a portal showing the related Courses to the Student and in that portal you placed the Classrooms::RoomNumber field, it will show the room number for that related Course.

Finally, out of curiosity, do you have a one-line portal?

[Zahary]

In your example, lets say you have Students, Courses, and Course Books? One student can have one or more corses, each course can have one or more books. Can you put on a single form without using some funky global variable(s) a means to select one student, a means to select one of the courses the student takes, and select one of the books the course requires that the student takes?

In Access this can be done with sub-forms. I have not gotten far enough in Filemaker to discover if sub-forms are possible.

>---------------------------------------<

It should stand to reason that if Filemaker has relative table process commands, that these commands could be available on any table, regardless of selected layout. I am trying to copy one or more selected rows (certain fields) to another table. My attempt was:

1. Load the content of the input table (Excel spreadsheet)

2. Process the columns in the table and insert the record into the final table

3. I cannot copy one record to another table without using global records nor import one table into another (for just one record?)

My gripe is not necessarily relational, however can be handled in an RDBMS using cursors. I may have misworded my gripe above.

Filemaker seems to deal with cursors using the current layout, however cannot handle more than one "cursor" in the same file? In other words, you cannot copy a record in one table to the record in another table because if you switch layouts you lose the data even if you have absolute references to your fields (tablename::fieldname).

The thing that kills me is this 'control-break' algorithm could even be done in gold old ancient COBOL with embedded SQL (ya ya single row processing vs set processing, i.e. why relational at all?)

[jrb12]

Zahary,

I began a reply to this thread a few days ago with a possible solution to your global fields problem. Then got called away and chucked the reply. Since then the thread has meandered a bit. But then your initial message contains a lot of food for thought.

I agree with you to a certain extent regarding FileMaker, the fact that a layout is part of a table is a serious limitation. One that I hoped would disappear in 7 when it became known that multi-table databases were possible. Unfortunately, its still the case that layout fields are table fields. That's really the problem, I think. That's why a layout needs to have a table to start from, picking up fields from other tables via relationships off the enclosing table.

But conceptually this is likely easier for a novice user to understand. My experience with non-IT users who develop with point and shoot applications is that they perceive their data as being stored in the manner in which they view it. The idea that there is a layer of intelligence between the screen and the data on the disk usually requires some eureka moment that takes awhile to occur. Granted FileMaker has calculation fields that may be considered as an intelligent link between layout and table. But they are embedded in the table, akin to a user defined field type in an SQL based system or a simple stored procedure.

In most every other DBMS, the user interface is separate from the data. Usually its SQL that provides the link between the two. And that's where the power that you require really resides. Building your address table is likely a single SQL insert statement with an embedded, perhaps complex, select statement to gather up the data from however many other tables are in play. No need even for a cursor.

But, this lack of separation is also what makes FileMaker so interesting, in my opinion. The imaginative workarounds that are needed to do something relatively simple in SQL, make for entertaining coding. Much more fun than COBOL over CODASYL ever was.

Getting back to your problem with globals. Will something like this work?

Define a relationship between the address table and your input table, that is based on a global in the address table and a unique key in the input table.

Define your address table fields with auto-enter lookups into the input table using this relationship.

Before storing a new record in the address table, set the global field to the record ID of the corresponding record in the input table.

This should copy the field contents across when you add the new address record.

I realize you have data coming from several records in the input table into a single record in the address table. Can these be considered different record types? If so, can each record type be imported into a different input table? Then define the lookups from the address table fields to use whichever input table relationship is appropriate and fill the global key fields accordingly.

Looking forward to your comments.

Cheers,

John.

[ffarmer]

I enjoyed your descriptions of FileMaker's "shortcomings"! As I attempt to convert a 10 table database from MS Access to FM7, I'm having a really difficult time getting my head around FileMaker's, er, "features".

Your suggested solution to Zahary's problem displays how wierd FM can be. I'm really discouraged. I think I'll go back to Access -- I like the separation of table, query, and report concept.

...Unless someone can convince me FileMaker is as good or better than Access.

(I use a Mac; unfortunately there is no Mac version of Access, so I have to use Virtual PC -- which emulates a PC, under the Mac OS -- running Windows and MS Office Pro. Talk about multi-levels of handshaking........!)

[Ron F]

Hey ffarmer,

Conversion to FM from access can be a major pain in the @$$ this is true. You might want to try converting your Access to Excel first then converting Excell to FMP its alot smoother. Also, I don't know how you are deploying your solution, are you in a network setting or stand alone. I'll give you to reasons to stick it out with FM7 right off the bat:

1) if it's stand alone - You can purchase FM Developer 7 then bind a runtime engine to your solution. This way you dont need to purchase desktop licenses for users. You solution has its own database engine in the form of runtime. Access doesn't do that.

2) IF You are networking your solution you can run FM7 Server and have much better security using Secure Sockets Layer (SSL) which encrypts the session between the desktop client and the server. Also most of your processing takes place on the server instead of on your desktop. Very fast and SQL like. There are also many more advantages to FM7 that you can research that may be helpful to you. I still use Access on a very limited basis, but I can tell you that FM7 does much more, it just does it differently.

3) One other thing Access still has a 2gb limit to each file in which you have to have all of your tables in one file. FM now has a virtualy limitless file size 8tb. and you can still link files to other files if you which plus have multiple files with a file, as you are aware of.

Try to stay with it a little longer and give it a chance.

Regards, Ron

[H.P.]

If you use a Mac or would like to develop cross platform solutions then you should definitely try to change to filemaker. It takes a while to get used to and able to do "almost" everything Access can do.

If you develop application only for windows then yes, stay with Ms. Access. You have more flexibility.

[ffarmer]

Thanks for your encouraging remarks. I am willing to give FM7 a fair go, but have hit a "wall" which is explained at point #6 below. My application is strictly "stand alone", on one Mac, for use on this Mac only (G4, OS10.2.8). Getting the data (10 tables) from MS Access to FM7 was quite easy. Recreating most of the reports, OK (with lots of 'trial & error' using intuition and Help menu!). I also created a "main panel" (layout) with buttons so I can easily invoke these reports.

Some of the problems ecountered are...

1) I haven't yet figured out how to easily (& elegantly) provide data selection criteria (dynamic Find parameters and/or dynamic Sort parameters) while requesting a report -- after clicking the button for it on the main report. Each time I request the report, I may want different record selections, or different sort orders. With the associated script, I can bring up the Find Mode screen, but this is not an "elegant" way to do it, especially when there are several AND and OR conditions. Very prone to errors/ommissions. I want to be able to enter the parameters in special fields on a panel, and pass them to FIND. Is there a way to "prompt" for the values using a script (without having to work directly with the Find Mode screen)?____ (this works well in MS Access)

2) On one of the reports, I use a pop-up list to select the value for a field. The values come from one of the tables. Fine. Except that if one value is ABCD1 and another is ABCD2, and I select either one of these I get all ABCD... data (!) in the report -- which I don't want!!! After selecting the value, I have to manually insert two '=' signs to ensure I retrieve only the exact match (e.g. ==ABCD1 to get ONLY ABCD1 data). Klutzy! Is there a better way?____ I'm surprised FM7's default Find matching is not an exact match. If I wanted all the ABCD data, I should be able to seek for ABCD* or ABCD?. But if I specify ABCD1, I should get only ABCD1 data!!

3) Zooming in on a report Preview produces an unreadable screen!! (I don't think this was a problem in previous versions of FM). Zoom works OK in Browse mode, but not in Preview mode. Hope this is fixed very soon. Font problem? I've tried various fonts.

4) Value list popups are poor as well, if displaying two fields (columns). They're not neatly aligned vertically, but rather the two fields appear concatenated and run together. Makes for a messy-looking popup list. Furthermore, one can't "sort" the list based on a third field. For example, my lists are typically a code and a description. But I like to force the order of these in a sequence other than basing it on the code or the description.

5) Running totals. Hmmmmmm. Imagine a report with detail lines, subtotals, and final total line. Each detail line has unitprice and quantity fileds, with a calculated "amount" field = unitprice X quantity. I also want another column showing a running total of this within each summary group. But if I create a Running Total field, it shows the same Grand Total on every line!! Useless. There must be a way -- I just haven't figured it out yet! This must be a very common requirement.

AMT CumulAMT

------ --------------

$20 $20

$15 $35

-$12 $23

$10 $33

6) And now (drum roll.....) here's the "wall" I've hit. Exporting to Excel. Two of my reports which are columnar in design (with column headings) also have sub total lines, and display selected data (from 3 tables), with some calculated fields. I want to export exactly what's on the reports to Excel for further processing (functions that FM doesn't have -- neither did MS Access, but at least in Access the export to Excel worked beautifully). In FM7, exporting to Excel requests that I select the originating fields from a table. I shouldn't have to go through all that again -- I can't even recall what they are, as they're part of the complex report layout. Furthermore, the report shows selected records, not all records. I don't want ALL records going to Excel -- only what's on the report. If I try Copy/Pasting from my report to Excel, I either get a graphic of the first Preview page of the report in Excel, or one line (record) of the Browse or Table view of the report. Again, useless!!! FM7 has been boasting about its ability to export to Excel. Tell me what I'm doing wrong. Please! This is my major hurdle. If I can get this to work properly, I can live with the other shortcomings. Otherwise, it's back to Access!

I'm trying to get off Access, because it requires some expensive software to run on a Mac (Virtual PC + Windows + MS Office Pro). My current versions of these won't run on a Mac G5 (which I'm planning to get). New versions of this software will hit me for C$1000 or more. Ouch. I'm hoping FM7 for Mac will do it all, so I wouldn't need Windows etc. (I have MS Office for Mac, but there is no Mac version of Access available). I am not a fan of Windows. Have been using Mac since 1985! So I REALLY want FM7 for Mac to work for me! Maybe it's all due to my lack of knowledge about FM7.

Any help with these problems (& other FM7 "problems"!), GREATLY appreciated. I've lost count of the hours/days/weeks spent doing this conversion. I hope I haven't wasted $$$ on FM7.

[Peterh]

1) Dynamic Find. Try something along the following lines:

Go to Layout

Enter Find Mode

Insert Calculated Result

Perform Find

The Insert Calculated Result is what can make your find dynamic. If you want to find a date range for example then have 2 global date fields and insert them into your find via the Insert Calculated Result. You can have as many as you want.

2) Use a calculated field which equals you popup list field. For example: "==" & popupListField

3) Yep, I find zooming a bit painful also.

This doesn't answer all your questions, but hopefully helps a bit.

Cheers, Peter.

[Ender]

That's a lot to cover in one thread, but there are solutions to most of those problems. To address your "hit the wall" problem, Yes you need to specify the export order, but only once for each type of report.

You can store the export order, in the Export script step (you can even specify the file name if you want.) To export summary results, put the sub-summary by fields in the 'Group by' section of the export dialog and make sure you use a Sort [ Restore ] script step right before the Export script step.

This kind of gets at the problem you stated in 1); where it sounds like you want to store finds and sorts but provide users choices.

For sorts, some reports require a very specific sort order for the sub-summaries to work. For these, just store one Sort [ Restore ] script step. With other reports and print outs, you'll want to give users choices. These can be scripted as well; either with a Custom Dialog or if there are many sort options, go to a layout that has buttons for predefined sorts. Custom Dialogs work fine for most of my reports, as three choices is usually enough.

For finds, I usually Restore the part of the find that is specific to the current report, then go to a "find" layout to allow users to narrow the find. For allowing OR criteria, you can make a button to Add Request (using a List layout is less confusing.) AND criteria happens whenever you enter something in more than one field. If the report needs to omit records, I usually do this after the user enters find criteria (omits need to be the last part of the requests.) This can be done by Adding a Request, telling it to Omit, and using Set Field to set the criteria.

[Kurt Knippel]

I think that everyone is focusing on the "layout" way to much. Filemaker has just as much seperation between data and interface as anything else, it is just that they happen to be stored in the same file. Layouts are only a "view" of the data. You could perform all of your functionality without any layouts in a file.

I am not sure what you have against using Global fields. Those are Filemaker's implementation of a Variable.

One limitation in Filemaker is that it cannot copy an entire record with a single simple command. Although you might actually be able to use a SQL INSERT command to do it.

What I would do to copy a single record from file A to file B would be to setup a relationship between the two with a Global in file B related to the RecordID in file A. Start with a script in file A which sets the Global in B, then calls a script in file B which copies the contents of the various fields via this relationship.

More work than a single SQL statement? Probably. But this is one instance and perhaps the most complicated one. Overall developing in Filemaker is MUCH faster than just about any other RDBMS.

[Fenton]

There are various ways to get data out of FileMaker. Going into Preview mode, copying and pasting, isn't what you'd use for Excel (it will give you a nice picture if pasted into an AppleWorks drawing document, which can then be Ungrouped and modified; but that's not really "data").

There is a Copy All Records command, which will copy all data on the current layout in Browse mode to the clipboard, tab-separated. If you paste that in Excel you get something resembling what you want.

If you want results that appear in Subsummary parts in Preview mode after a sort, which is what reports often have, then you need to define a field to obtain that result in Browse mode. This would be a calculation using the GetSummary() function, which requires a sort. If it's on the layout it will be copied; related fields on the layout are copied also.

You can Export as Merge (like comma-separated), then open with Excel, and you'll get the field names as the 1st row.

To automate this, you can use AppleScript to tell Excel to open the exported text file. There are AppleScript commands to copy records also. But you should be able to get what you want with FileMaker, enhanced with a little basic AppleScript, which could be as simple as:

set theFilepath to cell "field with Mac filepath"

tell application "Microsoft Excel" to Open "Mac filepath to the text file"

Put the above in a Perform AppleScript step. If "theFilePath" is not a global field, ie. an unstored calculation field, it may need to be on the layout at the time. I often have 1 layout dedicated to AppleScript related fields for this kind of thing. Switch there after the export.

(Of course, MS has to use a non-standard "Open" instead of "open file" like everyone else.)

[ffarmer]

Wow! Thanks for all the tips, guys. Lots to consider. I'd better print these out and try your advice. I'll be back if I run into any problems! In the meantime, I'll keep checking for further advice. I'm on the steep part of the learning curve.....

[ffarmer]

A comment re speed (of operation)....

I'm using a Mac G4/450MHz with OS 10.2.8 and OS 9.2.2, and 768MB of RAM (I can boot in either OS; I have to boot in OS9 in order to run Virtual PC for Access).

I have FileMaker Pro 7 running in OS 10.2.8.

I have MS Access95 (MS Office95), running under Windows95, running under Virtual PC 2.1 (a very old version), under OS 9.2.2.

I'm running both databases (FM7 version & Access version -- identical tables, identical data, identical reports etc) in parallel, until I'm satisfied that the FM7 version can do everything the Access version can do; the main outstanding problems are those stated above, so I'm about 85% "there").

Guess what? The Access95 version runs FASTER than the FM7 version!! ..despite all the layers under which Access is placed. FM7 is OK, but Access is snappier whenever I call up a report or screen, or go from page to page in a report Preview. I expected FM7 would work much faster since it's talking directly to the OS. I wonder if FM7 can be optimized further.

[ffarmer]

SUCCESS!

I've broken the "wall" and have successfully Exported the data I want to Excel and further processed it in Excel. Thanks for your tips and encouragement.

There's still a few other wrinkles to work out, but I hope to get past those too.

[dbruggmann]

Hello ffarmer

I don't know if you have seen this already: There's a new detailed (and free) article regarding the migration of an Access database to FM7 on www.filemakeradvisor.com

[Marlowe]

Reminds me of Mog and Ur.

Mog says to Ur,

[Marlowe]

Much of this sort of discussion between Access and FileMaker people reminds me of Mog and Ur.

Mog says to Ur,

[Tripod]

Zahary said:

Filemaker still requires you to link layouts to tables to access them. Example: Set Field( Table1::field, Table2::field) will always copy a blank value regardless of the field's content.

Not if there is a valid relationship.

Separation of data and design with a query language will always put Filemaker in a class with a standard spreadsheet program.

We have separation of data and design, but not a query language. This is the big difference. We have a scripting language in FMP. Not a query language, or a batch language. This is the fundamental difference. I don't believe you can have both. (I've not seen it, at least!)

I use Filemaker everyday to create elaborate SQL based front ends which make up for the endless relational deficiencies of Filemaker.

It's actually capable of most any relational function. Have you read any good books about it? Have you got your field types the same, and learned how to set up relationships? There are many many models of applying the rules of proper database design. You end up breaking a few (stretching them might be more appropriate) in FMP, for performance, etc... but that is also true in other environments.

Filemaker is far more relational than a spreadsheet! And moreso even than complex statistical programing languages, like SPSS. Maybe you need to ask some questions here about your relationships that are not working.

Filemaker is a great program if used for what it can do. Calling it a relational database is just wrong.

I have always seen it's relational capabilities as a strength, given that it is so good at layout and design and RAD type of situations.

Actually, I do not see where layouts are really linked to relationships at all. In the sense of their use in a script? Well, that seems logical enough, you are generally on the layout when the script is called. In layout mode, you can place fields based on relationships, and it doesn't matter what layout you are on. Once the relationship is made, it will work on any layout.

Just some thoughts...

--Tripod

[ffarmer]

Thanks for the reference, dbruggmann -- a good article. In my case, moving the data from Access95 tables to equivalent FM7 tables was quite easy. The biggest job has been recreating all the layouts and reports -- I'm still working on them (about 85% complete). A big problem was just having to learn FileMaker, as I hadn't really used it before. Also, Access uses different terminology and methods for doing things, than FM7 does. I'm more comfortable now, after a couple of weeks of effort. (Taking into account my time, it probably would have been just as cost effective to upgrade my Access, Windows, Virtual PC software!!! ...but with FM7, I now have something native to Mac OSX, so that's good too).

I'm still running the old Access system, as my benchmark, to ensure the results achieved in FM7 agree with Access. Many times they didn't and I find that scarey in FM7 -- it's very easy to get wrong calculation results with no warning. I'm still nervous about that.

The other area that bothers me is Relationships. In Access, you define inter-table relationships with each Query, and the results of a Query can also be treated just like a Table. In FM7, it seems the same Relationship diagram applies to all Layouts, but it's not always what I want. Or am I missing "something"?

In FM7, my tables are getting cluttered with so many calculation fields. This was not the case in Access.

I'll carry on with FM7. It'll do. I obviously need some education. In the meantime, I'll continue using this forum for advice. Thanks again.

[dbruggmann]

Regarding the way relationships work in FM 7 I would recommend you another article:

"Key Concepts in Filemaker 7" by Michael Harris ( www.digfm.org/ref/fm7_key_concepts.pdf )

Althoug written for Filemaker users, it is comprehensible also for

[CobaltSky]

ffarmer said:

In FM7, it seems the same Relationship diagram applies to all Layouts, but it's not always what I want. Or am I missing "something"?

Yes, I think you are indeed missing something.

In Filemaker 7, it is possible to set up a limitless number of separate relationship graphs (usually referred to as 'Table Occurrence Groups' or TOGs) so that if you wish, each layout in a file can be based on an entirely different relational structure all its own.

To do this, you simply place additional occurrences of the relevant tables onto the Relationships Graph (RG) - eg off to one side - and set up a new set of relationships to connect them, then base your layout on one of the table occurrences in this new and independent section of the RG. Delightfully simple and entirely open-ended.

ffarmer said:

In FM7, my tables are getting cluttered with so many calculation fields. This was not the case in Access.

It seems still more likely that you are missing something, if you are finding that you have a burgeoning agglomeration of calcs. In previous versions of FileMaker, calcs were sometimes used to ameliorate limitations in the structure, but for the most part these limitations have been removed in FileMaker 7, so it is not generally necessary to rely heavily on calculations. The fact that you are doing so seems to suggest that you may not making appropriate use of the relational capabilities and structural flexibility which is available in v7.

[Tripod]

Wow, I found the "Key Concepts in Filemaker 7" by Michael Harris ( www.digfm.org/ref/fm7_key_concepts.pdf )" to be a VERY informative read.

Now I see just how layouts are tied to table occurances.

I have not really used FM7 that much, still playing...

I found your link broken, but a google search quickly found the article.

This link was working for me: http://www.digfm.org/ref/FM7_key_concepts.pdf (You have to capitalize FM, I think.)

--Tripod

[ffarmer]

Thanks for the article. I have downloaded it, but will need some time to read (and absord) it! It seems to be quite different from my current concept of relational database. (I had no problem getting my head around Access -- I was familiar with mainframe RDBs a few years ago-- but FM7 is challenging my aging brain)! I will persist.....

[ffarmer]

I've hit another wall: Running Totals that don't "break" with the control breaks. Running totals in FM7 continue accumulating across all breaks. This is dumb. It's like adding apples + batteries + milkshakes. I want a Running Total that accumulates within each group, then starts over at the beginning of the next group.

I've just been advised by a consultant this can't be done (see my recent posting in the Layouts discussions, re Running Totals, in this forum). I'm astounded.

This is a show-stopper for me. Unless I get a quick solution real fast, it's back to Virtual PC + Windows + MS Access for relational databases on my Mac.

[Ron F]

This is my problem. Until now I was using a terminal services session for units I had in the field that connects via wireless. It was fast and worked quite well. Sin FMP has decided to mess with the graphics require much more resources for a a clean screen shot my 256 color terminal services sessions look like crap. I would have never pruchased to 10 seat + server package had I known that they've screwed this up so badly. That in addition to all the other messes I keep finding which have been posted on here. They better address it soon and come out with a 7.0v3 patch asap.

[CobaltSky]

ffarmer said:

I've just been advised by a consultant this can't be done...

Sounds like you've been talking to the wrong consultant.

See attached example.

Report.zip

[Neverland]

RonF -

Hard to tell from your message, but the REAL culprit could be Microsoft and not FileMaker. They made some changes to Terminal Services, including removing the limitation of 256 colors.

Check out Microsoft's knowledge base for more info --- there may be something there to help you out.

SR

[Ron F]

The only reason I think it's Filemaker is because when I run a terminal services session in FMP 6 it's fine. It just looks terrible in 7.

[ljk]

"2) IF You are networking your solution you can run FM7 Server and have much better security using Secure Sockets Layer (SSL) which encrypts the session between the desktop client and the server. Also most of your processing takes place on the server instead of on your desktop. Very fast and SQL like."

Said Ron F, but why not just tack on the microsoft SQL desktop engine to your access database for the required server side processing (and consequent reduced network traffic). In a networked environment an access database is often going to be the go over any fm offering. If the msde database size limit is reached just purchase SQL Server 2000 (cheaper than fm7 server depending upon your intended use) and upgrade via very simple upsizing wizard (after you discard your blobs). Scalability, Performance, Ease of use, Economy, Support, Interoperability (converting access to fm is a nightmare) are all reasons to use the microsoft solutions (Access + MSDE - - SQL Server) in a networked environment.

As a stand alone system though I can certainly see the merits of a non limited database size and would consider using filemaker 7 for this - save some money.

[ljk]

"2) IF You are networking your solution you can run FM7 Server and have much better security using Secure Sockets Layer (SSL) which encrypts the session between the desktop client and the server. Also most of your processing takes place on the server instead of on your desktop. Very fast and SQL like."

Said Ron F, but why not just tack on the microsoft SQL desktop engine to your access database for the required server side processing (and consequent reduced network traffic). In a networked environment an access database is often going to be the go over any fm offering. If the msde database size limit is reached just purchase SQL Server 2000 (cheaper than fm7 server depending upon your intended use) and upgrade via very simple upsizing wizard (after you discard your blobs). Scalability, Performance, Ease of use, Economy, Support, Interoperability (converting access to fm is a nightmare) are all reasons to use the microsoft solutions (Access + MSDE - - SQL Server) in a networked environment.

As a stand alone system though I can certainly see the merits of a non limited database size and would consider using filemaker 7 for this.