Filemaker vs Access for Large Records

My firm is creating a database that profiles (about 100) companies in
various sectors. Each profile is about 10 pages long with perhaps 150
parameters. Some of the parameters will contain a half a page of
information such as "recent press releases". Is there particular function
of Access that would make it better than Filemaker? I have done similar
projects on Filemaker. However, my experience with Access is does not deal
well with adding fields on the fly (I can't quite remember why this was, it
has been years). For example, three months we may add a section entitled
"investors", which will contain on average 400 words in each of the 100
profiles.

Any thoughts on the pros and cons of Filemaker vs. Access for large records.


Other data:
clients ~10
employees are onsite and travel
some contractors are in other states and will be working from home (not sure
if we will address this immediately)
we would like to use the same technology for basic reseach contacts and
business development contacts

re: Filemaker vs Access for Large Records

FileMaker does not deal well with 'adding fields on the fly' either. You
have to close all clients, define the new fields and then, depending on how
many records are in the file, wait for FileMaker while it adds the new
field. Even if you define the new fields in a copy of the file, the records
from the working file have to be imported into the copy and then the copy
opened for sharing. Either way, there is usually a bit of downtime when a
database is updated. Even with this issue, I would probably still recommend
FileMaker over Access. Access uses a lot of network bandwidth to get records
from the server to the client and even on small shared applications, it is
quite slow, unless you use MS SQL for the database engine and Access as the
front end to your application. Should you choose FileMaker over Access, I
would also recommend that you use FileMaker Server to host your database
files and you may want to use FileMaker Unlimited to host the database over
the internet. I don't see any issues with the record specifications. Each
text field you use will be limited to 64,000 characters which should be
sufficient to handle the data you are describing. I will note that FileMaker
7 will probably be released sometime this 1st quarter and this could also be
a factor as to whether or not you will want to use FileMaker or Access.
Here's a link to some information about FileMaker 7 and how it will be
different from prior versions.
http://www.thinksecret.com/news/filemaker7.html

Dave Herman

"Noesis Strategy" <none@none.com> wrote in message
news:40160025$0$27884$61fed72c@news.rcn.com...[color=blue]
> My firm is creating a database that profiles (about 100) companies in
> various sectors. Each profile is about 10 pages long with perhaps 150
> parameters. Some of the parameters will contain a half a page of
> information such as "recent press releases". Is there particular function
> of Access that would make it better than Filemaker? I have done similar
> projects on Filemaker. However, my experience with Access is does not[/color]
deal[color=blue]
> well with adding fields on the fly (I can't quite remember why this was,[/color]
it[color=blue]
> has been years). For example, three months we may add a section entitled
> "investors", which will contain on average 400 words in each of the 100
> profiles.
>
> Any thoughts on the pros and cons of Filemaker vs. Access for large[/color]
records.[color=blue]
>
>
> Other data:
> clients ~10
> employees are onsite and travel
> some contractors are in other states and will be working from home (not[/color]
sure[color=blue]
> if we will address this immediately)
> we would like to use the same technology for basic reseach contacts and
> business development contacts
>
>[/color]

re: Filemaker vs Access for Large Records

"Noesis Strategy" <none@none.com> wrote in message news:<40160025$0$27884$61fed72c@news.rcn.com>...[color=blue]
> My firm is creating a database that profiles (about 100) companies in
> various sectors. Each profile is about 10 pages long with perhaps 150
> parameters. Some of the parameters will contain a half a page of
> information such as "recent press releases". Is there particular function
> of Access that would make it better than Filemaker? I have done similar
> projects on Filemaker. However, my experience with Access is does not deal
> well with adding fields on the fly (I can't quite remember why this was, it
> has been years). For example, three months we may add a section entitled
> "investors", which will contain on average 400 words in each of the 100
> profiles.
>
> Any thoughts on the pros and cons of Filemaker vs. Access for large records.
> Other data:
> clients ~10
> employees are onsite and travel
> some contractors are in other states and will be working from home (not sure
> if we will address this immediately)
> we would like to use the same technology for basic reseach contacts and
> business development contacts[/color]

If you normalize properly, this is going to be a pretty small
database. Max size for Access, unless it's changed recently is 2GB.
if you are doing simple things with your reporting and don't really
need queries, then FileMaker is okay, but I found the lack of query
objects and the pseudo-relational aspect of it *really* annoying.
Maybe it's gotten better, but when I used it, I hated it. FileMaker
*may* be easier for web front ends, I don't know, but you can use
FrontPage to create those for Access, and they work.

"Creating fields on the fly" - this is a sign of poor design, usually.
You can do it just as easily in either application - but then you
have to fix all those forms/layouts/webpages, which is a lot of work.

So I guess it depends on exactly what you want to do with the data...
I think they can both handle it.

re: Filemaker vs Access for Large Records

"David Herman" <dpherman@NOSPAMmac.com> wrote in
news:RTvRb.6730436$Id.1094200@news.easynews.com:
[color=blue]
> Even with this issue, I would probably still recommend
> FileMaker over Access. Access uses a lot of network bandwidth to
> get records from the server to the client and even on small shared
> applications, it is quite slow,[/color]

This just not true, unless you are ignorant of how to write a
multi-user Access application. It only uses lots of network
bandwidth if you have a stupid design that is not properly indexed
and that constantly pulls far more records than needed for an
operation.

I don't know anything about Filemaker, so I won't comment on it.

I wish people who obviously know zilch about Access would do the
same.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: Filemaker vs Access for Large Records

Pieter Linden wrote:[color=blue]
> "Noesis Strategy" <none@none.com> wrote in message news:<40160025$0$27884$61fed72c@news.rcn.com>...
>[color=green]
>>My firm is creating a database that profiles (about 100) companies in
>>various sectors. Each profile is about 10 pages long with perhaps 150
>>parameters. Some of the parameters will contain a half a page of
>>information such as "recent press releases". Is there particular function
>>of Access that would make it better than Filemaker? I have done similar
>>projects on Filemaker. However, my experience with Access is does not deal
>>well with adding fields on the fly (I can't quite remember why this was, it
>>has been years). For example, three months we may add a section entitled
>>"investors", which will contain on average 400 words in each of the 100
>>profiles.
>>
>>Any thoughts on the pros and cons of Filemaker vs. Access for large records.
>>Other data:
>>clients ~10
>>employees are onsite and travel
>>some contractors are in other states and will be working from home (not sure
>>if we will address this immediately)
>>we would like to use the same technology for basic reseach contacts and
>>business development contacts[/color]
>
>
> If you normalize properly, this is going to be a pretty small
> database. Max size for Access, unless it's changed recently is 2GB.
> if you are doing simple things with your reporting and don't really
> need queries, then FileMaker is okay, but I found the lack of query
> objects and the pseudo-relational aspect of it *really* annoying.
> Maybe it's gotten better, but when I used it, I hated it. FileMaker
> *may* be easier for web front ends, I don't know, but you can use
> FrontPage to create those for Access, and they work.
>
> "Creating fields on the fly" - this is a sign of poor design, usually.
> You can do it just as easily in either application - but then you
> have to fix all those forms/layouts/webpages, which is a lot of work.
>
> So I guess it depends on exactly what you want to do with the data...
> I think they can both handle it.[/color]

"Maybe it's gotten better" indeed. When was the last time you used
FileMaker? When you speak of "psuedo-relational aspect of it" it sounds
like your last experience was may be with FileMaker 1 or 2? The current
shipping version is 6, with 7 expected soon. It has quite robust and
easily understood relational capabilities.

Bill

re: Filemaker vs Access for Large Records

"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns947D7AE73BB78dfentonbwaynetinvali@24.168.1 28.90...[color=blue]
> "David Herman" <dpherman@NOSPAMmac.com> wrote in
> news:RTvRb.6730436$Id.1094200@news.easynews.com:
>[color=green]
> > Even with this issue, I would probably still recommend
> > FileMaker over Access. Access uses a lot of network bandwidth to
> > get records from the server to the client and even on small shared
> > applications, it is quite slow,[/color]
>
> This just not true, unless you are ignorant of how to write a
> multi-user Access application. It only uses lots of network
> bandwidth if you have a stupid design that is not properly indexed
> and that constantly pulls far more records than needed for an
> operation.
>
> I don't know anything about Filemaker, so I won't comment on it.
>
> I wish people who obviously know zilch about Access would do the
> same.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

re: Filemaker vs Access for Large Records

filemaker fields can hold 64000 characters each.
we have files with hundreds of fields and over 100,000 records. When
printing a large field in filemaker you have to set the window size to the
maximum size possible. You can then set printing format to shrink the field
to fit the amount of data you have in the field. For this reason you may
want to use a separate form just for printing.

"Noesis Strategy" <none@none.com> wrote in message
news:40160025$0$27884$61fed72c@news.rcn.com...[color=blue]
> My firm is creating a database that profiles (about 100) companies in
> various sectors. Each profile is about 10 pages long with perhaps 150
> parameters. Some of the parameters will contain a half a page of
> information such as "recent press releases". Is there particular function
> of Access that would make it better than Filemaker? I have done similar
> projects on Filemaker. However, my experience with Access is does not[/color]
deal[color=blue]
> well with adding fields on the fly (I can't quite remember why this was,[/color]
it[color=blue]
> has been years). For example, three months we may add a section entitled
> "investors", which will contain on average 400 words in each of the 100
> profiles.
>
> Any thoughts on the pros and cons of Filemaker vs. Access for large[/color]
records.[color=blue]
>
>
> Other data:
> clients ~10
> employees are onsite and travel
> some contractors are in other states and will be working from home (not[/color]
sure[color=blue]
> if we will address this immediately)
> we would like to use the same technology for basic reseach contacts and
> business development contacts
>
>[/color]

re: Filemaker vs Access for Large Records

PS. In Filemaker you could add a database and relate it to the original with
no down time at all. However, downtime is really minimal, especially when
the field being added is not a calculation.
"ben polit" <polit@indiana.edu> wrote in message
news:bve45e$7f9$1@hood.uits.indiana.edu...[color=blue]
> filemaker fields can hold 64000 characters each.
> we have files with hundreds of fields and over 100,000 records. When
> printing a large field in filemaker you have to set the window size to the
> maximum size possible. You can then set printing format to shrink the[/color]
field[color=blue]
> to fit the amount of data you have in the field. For this reason you may
> want to use a separate form just for printing.
>
> "Noesis Strategy" <none@none.com> wrote in message
> news:40160025$0$27884$61fed72c@news.rcn.com...[color=green]
> > My firm is creating a database that profiles (about 100) companies in
> > various sectors. Each profile is about 10 pages long with perhaps 150
> > parameters. Some of the parameters will contain a half a page of
> > information such as "recent press releases". Is there particular[/color][/color]
function[color=blue][color=green]
> > of Access that would make it better than Filemaker? I have done similar
> > projects on Filemaker. However, my experience with Access is does not[/color]
> deal[color=green]
> > well with adding fields on the fly (I can't quite remember why this was,[/color]
> it[color=green]
> > has been years). For example, three months we may add a section[/color][/color]
entitled[color=blue][color=green]
> > "investors", which will contain on average 400 words in each of the 100
> > profiles.
> >
> > Any thoughts on the pros and cons of Filemaker vs. Access for large[/color]
> records.[color=green]
> >
> >
> > Other data:
> > clients ~10
> > employees are onsite and travel
> > some contractors are in other states and will be working from home (not[/color]
> sure[color=green]
> > if we will address this immediately)
> > we would like to use the same technology for basic reseach contacts and
> > business development contacts
> >
> >[/color]
>
>[/color]

re: Filemaker vs Access for Large Records

I have not worked with Filemaker before and I want to ask some
questions. It's great if you filemaker guys can answer them.

- What is the programming language behind filemaker? I saw something
called ScriptMaker on Filemaker website. Is it Filemaker's programming
language? How does it compare to VBA?

- Can we write SQL and execute them (like queries in Access)?

- Do filemaker forms have events (or triggers in Oracle Forms &
Reports)?
ie user's action triggering a piece of code. Eg: When opening a form
in Access we have OnLoad, Activate, OnOpen, ... For a textbox we have
OnClick, OnDoubleClick, BeforeUpdate, AfterUpdate, ...
Each objects in forms (and reports) in Access and Oracle Forms &
Reports have, in general, dozens of events.

- Does Filemaker have user and group level security?
ie user without an assigned username and valid password cannot run an
application and access data, and different users may have different
permissions on database objects. Eg: a normal employee should have no
right on anything about payroll.

NB

re: Filemaker vs Access for Large Records

If the replies are not totally wrong, then my conclusion is that
FileMaker is a good tools for toy-app, or uni kids' assignments

[color=blue]
> The most important difference is that FM does not separate data and
> structure.[/color]

! no comment

[color=blue][color=green]
> > - Do filemaker forms have events (or triggers in Oracle Forms &
> > Reports)?[/color]
> Well, we have some bad news here. Unfortunately, FM is a long way from
> any kind of object-oriented programming. There are plugins which will
> give you OnChange functionality to trigger events when a value in a
> field changes. Otherwise, no. Some of the events can be simulated in a
> totally locked down solution, but those are work-intensive to achieve so
> that you can run scripts on entry to a layout (form) or on exit. Sorry
> to say.[/color]

Hmm, no events. I can't imagine yet how I can develop a database
interface without events
[color=blue][color=green]
> > - Does Filemaker have user and group level security?
> > ie user without an assigned username and valid password cannot run an
> > application and access data, and different users may have different
> > permissions on database objects. Eg: a normal employee should have no
> > right on anything about payroll.[/color]
>
> Yes. The security is assignable to users and groups down to very fine
> levels, including allowing certain users to view layouts but not all
> fields on the layout. It's quite granular. Remember, though, that
> security is held in each file in a solution and so must be duplicated
> and managed in each file. Good news, bad news, eh?[/color]

If it can't assign permission to several objects at a time then it's a
real bad news. Look at my app, which is an average Access app: about
57 tables, 135
queries, 120 forms, 48 reports, and 20 code modules. It would be a
pain in the bum to define permission for 6 user groups, for each and
every object.

Access is not perfect here too. You can't import security permission
from another app.
[color=blue]
> Download the demo, as I said. If you want a bit of FM interface flavor
> with the ability to interact directly with SQL and more of the interface
> goodies you want, go look at www.servoy.com. :)[/color]
[color=blue]
> FM has a lot of positive features, but it is not the tool for every
> application. It is, however, among the most FUN (in an extremely geeky
> sense of "fun") db tools to work with. Way more fun than Access. ;)[/color]


I doubt it, mate

NB