f



FileMaker 7 - must be damn good

I used to have an impression that FileMaker is no good for serious DB
application development work. But with the new version 7, I think I'll
have to change my opinion.

I am quite amazed by the specs: 8 TB limit, relationship window, and
it seems they have both user "and" group level security, and also form
and report events (?).

Overall, FM7 adopts many of the good features of Access.

Bboth camps: Access and FM, your 2c please.

NB
0
nickbose
6/23/2004 3:49:33 AM
comp.databases.filemaker 11053 articles. 0 followers. amosw01 (46) is leader. Post Follow

359 Replies
3063 Views

Similar Articles

[PageSpeed] 4

NB wrote:
> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.
> 
> NB

Someone else may be able to answer this related question.

One thing I love about Filemaker is how a layout is independent of the 
record set under it. Switching from a list to a detail layout in the 
same window is a piece of cake, and instantaneous (I've always been 
impressed with it's speed when it comes to elaborate layouts, I can't 
visually detect changes).

What's the best way to accomplish the functionality in Access?

In the current DB I'm working on, I'm using a continuous form split in 
half, the top for selecting the records (and header with controls for 
filtering them), the footer for displaying the record's contents for 
editing (there aren't that many fields in this case, so it's easy to fit 
in all in). I'm thinking the best way to accomplish this functionality I 
like in Filemaker might be to do something similar, but use code to 
resize the footer between nothing, and taking up the whole screen. Is 
there any validity to this?

In another case, I just opened another form with the same underlying 
query, filtered in the same way, maximised and modal, so as not to 
suggest there's anything else under there. Upon opening went to the same 
record as the underlying form, upon closing made the underlying form go 
to the record this top one was on (I wanted record selectors in the 
detail form as well, as opposed to forcing the user to close it to get 
to another one). There has to be a better way than this surely?

What do most Access developers do in this case?

Back to Filemaker, there's a certain irony to the program. A Filemaker 
database can have so many dummy fields/relationships and layout hopping 
to achieve certain tasks, a Filemaker solution can be more daunting and 
unwieldy to a person that didn't create it, than something with the 
equivalent functionality in Access would. This is a bit better in 7, but 
it's still an issue. If my boss would have paid for Filemaker, I would 
have created a real mother of a database in it, and god help whoever was 
going to want to change it drastically if I left (I live in a small town 
where there may not be anyone else that knows about it). I did start to 
have something to show in order to convince him (back then I wasn't up 
to the task of creating anything decent in Access) and it wasn't pretty 
when it came to all the hacks I was using in it. I like/hate both 
products for different reasons.
0
I
6/23/2004 10:19:48 AM
I'm a Trampoline wrote:
> 
> Someone else may be able to answer this related question.
> 
> One thing I love about Filemaker is how a layout is independent of the 
> record set under it. Switching from a list to a detail layout in the 
> same window is a piece of cake, and instantaneous (I've always been 
> impressed with it's speed when it comes to elaborate layouts, I can't 
> visually detect changes).
> 
> What's the best way to accomplish the functionality in Access?
> 
> In the current DB I'm working on, I'm using a continuous form split in 
> half, the top for selecting the records (and header with controls for 
> filtering them), the footer for displaying the record's contents for 
> editing (there aren't that many fields in this case, so it's easy to fit 
> in all in). I'm thinking the best way to accomplish this functionality I 
> like in Filemaker might be to do something similar, but use code to 
> resize the footer between nothing, and taking up the whole screen. Is 
> there any validity to this?

To avoid any confusion, this above is about Access in a crossposted 
thread in an Access group, I perhaps should have removed the crosspost 
to the Filemaker group. Reading it back to myself, the wording can be a 
bit ambiguous as to what product I'm talking about. Sorry for any confusion.
0
I
6/23/2004 10:34:26 AM
nickbose@softhome.net (NB) wrote in message news:<5240fc76.0406221949.33e1f4e2@posting.google.com>...
> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.

I always thought even v4 was better than Access. I think the specs
that you have named are among the least exciting. It seems clear that
you have never tried it, maybe give it a try and then see what you
think.
0
paul
6/23/2004 12:57:55 PM
NB wrote:

> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.

Access has good features? ;-)

Seriously, the development methodology of FM and Access are radically 
different from each other. Many Access developers have prematurely 
written off FM because they simply didn't know how to use it. For 
example, your comment that "FM is no good for serious DB application 
development work" is completely and utterly false. It's just different 
from Access and other DBMS's.

Access' strength is that it has a complex programming language that lets 
developers code intricate features, provided they take the time to learn 
VB. But then again, 4D has an extensive language too. I would sooner use 
4D than Access if I wanted a programming-based database. And 4D is cross 
platform too. I really don't see the draw to Access, other than people 
typically get free copies because their bosses shelled out for Office Pro.

FileMaker's strength is that a lot of functionality is done for you and 
it is quicker and easier to get a solution up and running. It caters 
more to the database designer rather than a software developer.
0
Kevin
6/23/2004 12:59:23 PM
I disagree.  I gave it a try hoping for something better than Access.  I
tried FM and also Alpha Software.  In both cases, I gave up.  Went back with
Access, which is much better IMO.  FM is not particularly cheap either.
There is only one feature that I miss in Access.   FM flies (I had the
network version); speed of processing data is very good.

> FileMaker's strength is that a lot of functionality is done for you and
> it is quicker and easier to get a solution up and running. It caters
> more to the database designer rather than a software developer.


0
Saintor
6/23/2004 3:24:55 PM
Hello

FM 7 as all previous versions cannot be compared to an end user tool like
access. First the scripting used by access is VBS the scripting used by
FMPro is internal within FM Pro and on MAC OS X is supported totally by
applescript.
The performance of FM Pro 7 compared to Access make those two products in
different leagues. Access being the childstool.

Some remarks about FMP 7.
The performance is really great - unless you are uploading from e.g. Tab
separated data files then avove 250000 records per embadded table the
performance is going down. Yet after importing the performance is blazing,
even better then MS SQL Server.

It seems from large imports that the performance of FMP 7 stays amazing
specially when using proper indexes - all content of e.g. A test field is in
effect indexed, and one field can contain up to 4 GB data. I cant see any
other database even come close to that amount.

When using value list from a related table the finding of one record in a
large set isn't supported as in FMP 6, Filemaker is looking into that as
well.

Another great feature is instant views of datasets: the same found amound of
records can be presented in any chosen way.
The scripting language is formidable, but totally different from VBS.

Yet after a short learning process it will be very easy to use.

Regards

Rob



On 23-06-2004 5:49, in article
5240fc76.0406221949.33e1f4e2@posting.google.com, "NB"
<nickbose@softhome.net> wrote:

> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.
> 
> NB

0
Office
6/23/2004 5:50:35 PM
Hello

FM 7 as all previous versions cannot be compared to an end user tool like
access. First the scripting used by access is VBS the scripting used by
FMPro is internal within FM Pro and on MAC OS X is supported totally by
applescript.
The performance of FM Pro 7 compared to Access make those two products in
different leagues. Access being the childstool.

Some remarks about FMP 7.
The performance is really great - unless you are uploading from e.g. Tab
separated data files then avove 250000 records per embadded table the
performance is going down. Yet after importing the performance is blazing,
even better then MS SQL Server.

It seems from large imports that the performance of FMP 7 stays amazing
specially when using proper indexes - all content of e.g. A test field is in
effect indexed, and one field can contain up to 4 GB data. I cant see any
other database even come close to that amount.

When using value list from a related table the finding of one record in a
large set isn't supported as in FMP 6, Filemaker is looking into that as
well.

Another great feature is instant views of datasets: the same found amound of
records can be presented in any chosen way.
The scripting language is formidable, but totally different from VBS.

Yet after a short learning process it will be very easy to use.

Regards

Rob



On 23-06-2004 5:49, in article
5240fc76.0406221949.33e1f4e2@posting.google.com, "NB"
<nickbose@softhome.net> wrote:

> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.
> 
> NB

0
Rob
6/23/2004 5:52:54 PM
Saintor wrote:
> I disagree.  I gave it a try hoping for something better than Access.  I
> tried FM and also Alpha Software.  In both cases, I gave up.  Went back with
> Access, which is much better IMO.  FM is not particularly cheap either.
> There is only one feature that I miss in Access.   FM flies (I had the
> network version); speed of processing data is very good.

What couldn't FM do that you wanted?
0
Kevin
6/23/2004 6:34:25 PM
Hello

FM 7 as all previous versions cannot be compared to an end user tool like
access. First the scripting used by access is VBS the scripting used by
FMPro is internal within FM Pro and on MAC OS X is supported totally by
applescript.
The performance of FM Pro 7 compared to Access make those two products in
different leagues. Access being the childstool.

Some remarks about FMP 7.
The performance is really great - unless you are uploading from e.g. Tab
separated data files then avove 250000 records per embadded table the
performance is going down. Yet after importing the performance is blazing,
even better then MS SQL Server.

It seems from large imports that the performance of FMP 7 stays amazing
specially when using proper indexes - all content of e.g. A test field is in
effect indexed, and one field can contain up to 4 GB data. I cant see any
other database even come close to that amount.

When using value list from a related table the finding of one record in a
large set isn't supported as in FMP 6, Filemaker is looking into that as
well.

Another great feature is instant views of datasets: the same found amound of
records can be presented in any chosen way.
The scripting language is formidable, but totally different from VBS.

Yet after a short learning process it will be very easy to use.

Regards

Rob


On 23-06-2004 5:49, in article
5240fc76.0406221949.33e1f4e2@posting.google.com, "NB"
<nickbose@softhome.net> wrote:

> I used to have an impression that FileMaker is no good for serious DB
> application development work. But with the new version 7, I think I'll
> have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window, and
> it seems they have both user "and" group level security, and also form
> and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.
> 
> NB

0
Rob
6/23/2004 6:46:12 PM
Sorry for double sending


On 23-06-2004 20:46, in article BCFF9C94.4E375%cassiope@wanadoo.nl, "Rob
Tito" <cassiope@wanadoo.nl> wrote:

> Hello
> 
> FM 7 as all previous versions cannot be compared to an end user tool like
> access. First the scripting used by access is VBS the scripting used by
> FMPro is internal within FM Pro and on MAC OS X is supported totally by
> applescript.
> The performance of FM Pro 7 compared to Access make those two products in
> different leagues. Access being the childstool.
> 
> Some remarks about FMP 7.
> The performance is really great - unless you are uploading from e.g. Tab
> separated data files then avove 250000 records per embadded table the
> performance is going down. Yet after importing the performance is blazing,
> even better then MS SQL Server.
> 
> It seems from large imports that the performance of FMP 7 stays amazing
> specially when using proper indexes - all content of e.g. A test field is in
> effect indexed, and one field can contain up to 4 GB data. I cant see any
> other database even come close to that amount.
> 
> When using value list from a related table the finding of one record in a
> large set isn't supported as in FMP 6, Filemaker is looking into that as
> well.
> 
> Another great feature is instant views of datasets: the same found amound of
> records can be presented in any chosen way.
> The scripting language is formidable, but totally different from VBS.
> 
> Yet after a short learning process it will be very easy to use.
> 
> Regards
> 
> Rob
> 
> 
> On 23-06-2004 5:49, in article
> 5240fc76.0406221949.33e1f4e2@posting.google.com, "NB"
> <nickbose@softhome.net> wrote:
> 
>> I used to have an impression that FileMaker is no good for serious DB
>> application development work. But with the new version 7, I think I'll
>> have to change my opinion.
>> 
>> I am quite amazed by the specs: 8 TB limit, relationship window, and
>> it seems they have both user "and" group level security, and also form
>> and report events (?).
>> 
>> Overall, FM7 adopts many of the good features of Access.
>> 
>> Bboth camps: Access and FM, your 2c please.
>> 
>> NB
> 

0
Rob
6/23/2004 6:52:31 PM
Rob Tito <cassiope@wanadoo.nl> wrote in
news:BCFF9C94.4E375%cassiope@wanadoo.nl: 

> A test field
> is in effect indexed, and one field can contain up to 4 GB data. I cant
> see any other database even come close to that amount.

A field of 4 gig?

Indexed?

Uh huh! This is exactly what everybody needs ...!

-- 
Lyle
(for e-mail refer to http://ffdba.com/)
0
Lyle
6/23/2004 7:42:59 PM
"Rob Tito" <cassiope@wanadoo.nl> wrote in message
news:BCFF9C94.4E375%cassiope@wanadoo.nl...

> Hello
>
> FM 7 as all previous versions cannot be compared to an end user tool like
> access. First the scripting used by access is VBS

WRONG WRONG WRONG!

The programming language in ms-access is the same as VB6. It is the same
core, and even shares the same compiler. All of the tools such as the soap
kit add ins, the com add ins, and even Visual Source for source code control
and project management all work with VBA in ms-access.

You are confusing VBS (which is a windows scripting language, and quite
limited at that). Ms-access uses VBA (Visual Basic for Applications). VBA,
for all given purposes is the same langue, and even same code engine as VB6,
but with the ms-access forms model.

So, to compare the rich, and well established VB ide that ms-access comes
with to lame VBS scripting langue is a rather HUGE insult to all access
developers. If you are going to make a comparisons here..at least spend some
time to learn what heck you are talking about.

> The performance of FM Pro 7 compared to Access make those two products in
> different leagues. Access being the childstool.

Really. Where did you get such comparisons here? Are you talking about the
server based editing of FileMaker (or the server based edition of
ms-access?). You are aware that ms-access ADP projects are 100% native OLEdb
sql server based applications..right?

If you are going to compare FileMaker to the JET database engine in a file
share mode, then you BETTER be running FilkeMaker as a file share also, and
NOT be running the server based component part.

If you are going to run the server based part in FileMaker, then you better
to the same with ms-access. Once again, you seem to be trying to compare
applies and oranges based on your lack of knowledge here.  For the LAST
THREE VERSIONS OF ms-access, the 100% compatible sql server engine has been
on the office cd, and is provided for building client to server applications
NATIVELY with ms-access.

So, please show me the well thought out,a nd performance bench mark you
speak of?

> Another great feature is instant views of datasets: the same found amound
of
> records can be presented in any chosen way.

You mean the query feature of ms-access, that it had in 1992? 14 years ago
on windows 3.1?

> The scripting language is formidable, but totally different from VBS.

Yes, and the programming language in ms-access is also totally different
from VBS, or some scripting thingy that FileMaker has.

So, at least lets be clear that VBA, and ms-access have little, or no
relation to VBS.

I not interested in some Ford vs Chevy argument like I used to a have in
high school. I am long past that child like stage.

Products like FikeMaker are well established products, and deserve their
rightfully respect. However, lets at least make sure when comparing
things...we try and get the facts right, and know exaclty what we are
comparing!!

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/23/2004 7:50:55 PM
Kevin Hayes <me@here.com> wrote:

> Many Access developers have prematurely 
> written off FM because they simply didn't know how to use it.

it takes time to understand the real features of FMP

all the good things you can do with links INTO your own table, in a
portal... very amazing, and so simple and powerful. The first time I
tried it, I couldn't think it will work. But it did !

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/23/2004 11:16:19 PM
Lyle Fairfield <MissingAddress@Invalid.Com> wrote:

>> A test field
>> is in effect indexed, and one field can contain up to 4 GB data. I cant
>> see any other database even come close to that amount.
>
>A field of 4 gig?
>
>Indexed?
>
>Uh huh! This is exactly what everybody needs ...!

<chuckle>  Google on your own system.

Tony
--
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
http://www.granite.ab.ca/accsmstr.htm
0
Tony
6/24/2004 12:17:05 AM
RE/
>In the current DB I'm working on, I'm using a continuous form split in 
>half, the top for selecting the records (and header with controls for 
>filtering them), the footer for displaying the record's contents for 
>editing (there aren't that many fields in this case, so it's easy to fit 
>in all in). I'm thinking the best way to accomplish this functionality I 
>like in Filemaker might be to do something similar, but use code to 
>resize the footer between nothing, and taking up the whole screen. Is 
>there any validity to this?

That's pretty close to my standard Access app except I use a scrolling list on
the left side of the window and present detail on the right side.

Using a ListBox, you put code in the list box's AfterUpdate event to refresh the
details.   Typically, I have a two-column listbox with the record id in the
invisible first column and identifying info (like person's name, project number,
whatever...) in the visible column.

For a bound implementation, you just point the detail query to an invisible
field on the form that contains the recordID of the currently-selecte list row.

In the listbox's AfterUpdate, you set that field to lstWhatever.Column(0) and
then issue a Me.Requery to refresh the query's recordset for the details.
-- 
PeteCresswell
0
Pete
6/24/2004 1:12:39 AM
"Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in
news:zalCc.860394$oR5.10370@pd7tw3no: 

> You are confusing VBS (which is a windows scripting language, and quite
> limited at that).

quite limited?


-- 
Lyle
(for e-mail refer to http://ffdba.com/)
0
Lyle
6/24/2004 1:14:40 AM
RE/
>Overall, FM7 adopts many of the good features of Access.

Can you split the app into back end and front end?   Does it support ODBC?
-- 
PeteCresswell
0
Pete
6/24/2004 1:15:00 AM
(Pete Cresswell) wrote:
>>Overall, FM7 adopts many of the good features of Access.

> Can you split the app into back end and front end?   

For the most part, yes.  Certainly as well as you can in Access, if not 
better.

> Does it support ODBC?

Yes -- FileMaker's done this since version 5.5

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/24/2004 1:17:43 AM
nickbose@softhome.net (NB) wrote in
news:5240fc76.0406221949.33e1f4e2@posting.google.com: 

> I used to have an impression that FileMaker is no good for serious
> DB application development work. But with the new version 7, I
> think I'll have to change my opinion.
> 
> I am quite amazed by the specs: 8 TB limit, relationship window,
> and it seems they have both user "and" group level security, and
> also form and report events (?).
> 
> Overall, FM7 adopts many of the good features of Access.
> 
> Bboth camps: Access and FM, your 2c please.

I've just recently observed a discussion in another online forum
where a FM user was pulling her hair out trying to break down a
poorly designed field into multiple fields (several independent
pieces of data were packed into the single field). She had lots of
trouble copying the data into the new fields. 

In today's world, if it doesn't support SQL, I'm sorry, but it's not
really a serious database product. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 1:56:04 AM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in 
news:40DA2BB7.2030909@antispahm.fmprosolutions.com:

> (Pete Cresswell) wrote:
>>>Overall, FM7 adopts many of the good features of Access.
> 
>> Can you split the app into back end and front end?   
> 
> For the most part, yes.  Certainly as well as you can in Access, if not 
> better.

How do you know how well Pete can ... or do you mean ... as well as Howard 
can ... and how "well" is that? ... and in what way might it be "better"?

-- 
Lyle
(for e-mail refer to http://ffdba.com/)
0
Lyle
6/24/2004 2:04:44 AM
Office 2004 Test Drive User <cassiope@wanadoo.nl> wrote in
news:BCFF8F8B.4E327%cassiope@wanadoo.nl: 

> FM 7 as all previous versions cannot be compared to an end user
> tool like access. . . .

To me, it seems you've got it exactly backwards here -- FM is the
one that is primarily and end-user with meager scripting support.
Everything in it is designed to be easy for point and clickers (this
is not a bad thing, of course). Access started out with the same
goals but is not as end-user-friendly, from what I understand about
it (I downloaded the FM7 demo a while back but never got around to
trying it out). 

But Access provides power and control at the highest level to any
programmer who wants to use it. 

> . . . First the scripting used by access is VBS . . .

VBScript? Er, no, it's not VBScript, it's VBA, Visual Basic for
Applications, which is a subset of full VB (actually, VB is a
superset of VBA, since VB and VBA use the same core DLL). 

> . . . the
> scripting used by FMPro is internal within FM Pro and on MAC OS X
> is supported totally by applescript.
> The performance of FM Pro 7 compared to Access make those two
> products in different leagues. Access being the childstool.

Performance of what kind? Delivery of data? Speed of opening?

And on what basis is the comparison made? Perhaps the slow Access
app was extremely poorly designed. 

> Some remarks about FMP 7.
> The performance is really great - unless you are uploading from
> e.g. Tab separated data files then avove 250000 records per
> embadded table the performance is going down. Yet after importing
> the performance is blazing, even better then MS SQL Server.

I have no idea what any of that means. "Better than MS SQL Server"
in what way? It delivers the same amount of data faster? 

> It seems from large imports that the performance of FMP 7 stays
> amazing specially when using proper indexes - all content of e.g.
> A test field is in effect indexed, and one field can contain up to
> 4 GB data. I cant see any other database even come close to that
> amount. 

4GBs in a single field? Why would anyone need that?

> When using value list from a related table the finding of one
> record in a large set isn't supported as in FMP 6, Filemaker is
> looking into that as well.

In other words, the most basic of database-related activities is not
supported. 

> Another great feature is instant views of datasets: the same found
> amound of records can be presented in any chosen way.
> The scripting language is formidable, but totally different from
> VBS. 

VBA. Different is not better. It's just different.

> Yet after a short learning process it will be very easy to use.

But no SQL. Ridiculous.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 2:05:38 AM
Office 2004 Test Drive User <cassiope@wanadoo.nl> wrote in
news:BCFF8F8B.4E327%cassiope@wanadoo.nl: 

> It seems from large imports that the performance of FMP 7 stays
> amazing specially when using proper indexes - all content of e.g.
> A test field is in effect indexed, and one field can contain up to
> 4 GB data. I cant see any other database even come close to that
> amount. 

What Access can do with data storage depends on which of the many
back end database engines one is use Access with. I believe FM has
some ODBC support and can connect to data other than just its native
format, but Access offers a very wide variety of such sources. 

So, really, a comparison of how much can be stored in a single field
is really not about Access, but about it's native database engine,
Jet. But if you're using a different back end with your Access front
end, Jet does not have anything to do with the type or amount of
data that can be stored. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 2:10:38 AM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:40DA2BB7.2030909@antispahm.fmprosolutions.com: 

> (Pete Cresswell) wrote:
>>>Overall, FM7 adopts many of the good features of Access.
> 
>> Can you split the app into back end and front end?   
> 
> For the most part, yes.  Certainly as well as you can in Access,
> if not better.

Please explain what's better about FM's splitting of the app.

And, as Albert recommends, don't confuse the issue by comparing FM
with its server-side database engine to Access with just Jet. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 2:13:28 AM
Lyle Fairfield wrote:

> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in 
> news:40DA2BB7.2030909@antispahm.fmprosolutions.com:
> 
> 
>>(Pete Cresswell) wrote:
>>
>>>>Overall, FM7 adopts many of the good features of Access.
>>
>>>Can you split the app into back end and front end?   
>>
>>For the most part, yes.  Certainly as well as you can in Access, if not 
>>better.
> 
> 
> How do you know how well Pete can ... or do you mean ... as well as Howard 
> can ... and how "well" is that? 

You can put the database tables in one or more files, and put the front 
end layouts and scripts in one or more different files. You can have 
multiple front ends accessing the same files.

>... and in what way might it be "better"?

It might be better if it provided more tools to assist the user/develop 
in maintaining that boundary.
0
42
6/24/2004 2:25:48 AM
David W. Fenton wrote:

> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
> news:40DA2BB7.2030909@antispahm.fmprosolutions.com: 
> 
> 
>>(Pete Cresswell) wrote:
>>
>>>>Overall, FM7 adopts many of the good features of Access.
>>
>>>Can you split the app into back end and front end?   
>>
>>For the most part, yes.  Certainly as well as you can in Access,
>>if not better.
> 
> 
> Please explain what's better about FM's splitting of the app.
> 
> And, as Albert recommends, don't confuse the issue by comparing FM
> with its server-side database engine to Access with just Jet. 

I would think it would be far more confusing to the issue to try and 
compare FM to Access + Oracle or another enterprise RDBMS backend don't you?
0
42
6/24/2004 2:29:49 AM
David W. Fenton wrote:

> I've just recently observed a discussion in another online forum
> where a FM user was pulling her hair out trying to break down a
> poorly designed field into multiple fields (several independent
> pieces of data were packed into the single field). She had lots of
> trouble copying the data into the new fields. 
> 
> In today's world, if it doesn't support SQL, I'm sorry, but it's not
> really a serious database product. 

Well, it's a shame that the user was pulling her hair out.  But her 
situation could have just as easily been the case in Access.  Access 
doesn't prevent poorly designed fields, nor does Access have any wizards 
that will automatically split data out into multiple fields.

FM's SQL support definitely is not as robust as it is in Access.  But 
that doesn't mean that doing what this woman wanted to do is any more 
difficult to do in FileMaker then in Access or in SQL Server.  Based on 
why she was in her predicment in the first place, I doubt she knows SQL. 
  And for a newbie walking opening both Access and FileMaker for the 
first time, I am guessing that FM would be quicker to pick up.  I don't 
doubt that Access is more powerful, but I think FMP is more intuitive.

> To me, it seems you've got it exactly backwards here -- FM is the
> one that is primarily and end-user with meager scripting support.
> Everything in it is designed to be easy for point and clickers (this
> is not a bad thing, of course). Access started out with the same
> goals but is not as end-user-friendly, from what I understand about
> it (I downloaded the FM7 demo a while back but never got around to
> trying it out). 
> 
> But Access provides power and control at the highest level to any
> programmer who wants to use it. 

Again, there is no question that Access is more flexible and powerful in 
its scripting.  I believe that Access can do absolutely anything if a VB 
programmer gets his/her hands on it.  But that might be a steep learning 
curve for someone who just wants to build a database.  Whenever I've 
tried building anything more than a basic Access solution, I have run 
into the obstacle of needing to know some VB.  While FileMaker can't 
itself be controlled by VB, it does have some ActiveX controls and it 
can also incorporate any VB into its scripts to control other 
applications.  This makes it simple enough to integrate data with other 
apps.

Don't get me wrong -- there are certainly some features that I'd love to 
see built in to FileMaker, just as I'm sure there are things you'd like 
to see built into Access.  But lacking those desired features doesn't 
inhibit FileMaker developers from building what they want to build.  And 
with very few exceptions, there is little that Access can do that FMP 
can't.  I would argue, though, that someone with equal knowledge of both 
apps might be able to build a solution more quickly in FMP than they 
could in Access.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/24/2004 2:35:05 AM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote:

> And 
> with very few exceptions, there is little that Access can do that FMP
> can't.  I would argue, though, that someone with equal knowledge of both
> apps might be able to build a solution more quickly in FMP than they 
> could in Access.

And there's that still-important factor....cross-platforming.

When the question is "what about my Mac?" Access isn't the answer.

Lynn Allen
--
Allen & Allen Semiotics        www.semiotics.com
FSA Associate       Filemaker Design & Consulting  
0
lynn
6/24/2004 2:39:46 AM
David W. Fenton wrote:
>>(Pete Cresswell) wrote:
>>
>>>>Overall, FM7 adopts many of the good features of Access.
>>
>>>Can you split the app into back end and front end?   
>>
>>For the most part, yes.  Certainly as well as you can in Access,
>>if not better.
> 
> Please explain what's better about FM's splitting of the app.

To be fair, I haven't opened Access in more than a year.  I am looking 
at Access 7.  I'm sure you'll correct me if I'm wrong or if things have 
changed.

Like FileMaker, Access files combine multiple data tables, forms, macros 
and other objects into a single file.  But it seems that Access can only 
have one file open at a time, whereas FMP can have multiple files open. 
  This means that you can have an interface file separate from your data 
file.  You can set up seamless references and relationships between the 
multiple tables in the multiple files.  Your interface file, in fact, 
doesn't even need to have any data tables defined.

 > And, as Albert recommends, don't confuse the issue by comparing FM
 > with its server-side database engine to Access with just Jet.

I'm not familiar with Jet or whatever you're suggesting.  But I think 
what we are really comparing here are the base applications on their 
default servers.  I am thinking about hardware/software costs, 
development/setup time, cross-platform capability, intuitive user 
interface and (from what I'm told; I've admittedly no firsthand 
experience with this) server/client communication speed...Filemaker 
would be the hands-up winner.  Based on potential programming power and 
potential configurations, I'll give it to Access.  Different 
applications, different markets, different user base

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/24/2004 3:11:12 AM
"David W. Fenton"  wrote...
> 4GBs in a single field? Why would anyone need that?


"640k should be enough for anybody."
                  - - Bill Gates, 1981

Maybe you're too young to remember where that one got us?

Kent


0
K
6/24/2004 3:35:05 AM
On Wed, 23 Jun 2004 22:35:05 -0500, K&V P wrote
(in article <JZrCc.874213$Ig.666717@pd7tw2no>):

> "640k should be enough for anybody."
>                   - - Bill Gates, 1981

Back in 1978 I was taken on a tour of the computer facilities of what was 
then perhaps the nation's foremost purveyor of computer based econometric 
information. Part of the facility was a large room, I'd say perhaps 40 by 80 
feet, which contained nothing but a veritable sea of Burroughs 40 inch 
platter hard disk drives. I commented to my host that I'd never in my then 20 
years of computing seen so much disk storage in one location, and I asked how 
much storage there was. The answer.....    "just over a gigabyte!"

I can also remember paying almost $5,000 for a hard drive for my Apple III.


-- James L. Ryan -- TaliesinSoft

"My dog never came across a bush he didn't like!"

0
James
6/24/2004 4:13:34 AM
Howard Schlossberg wrote:

> David W. Fenton wrote:
> 
>> I've just recently observed a discussion in another online forum
>> where a FM user was pulling her hair out trying to break down a
>> poorly designed field into multiple fields (several independent
>> pieces of data were packed into the single field). She had lots of
>> trouble copying the data into the new fields.
>> In today's world, if it doesn't support SQL, I'm sorry, but it's not
>> really a serious database product. 
> 
> 
> Well, it's a shame that the user was pulling her hair out.  But her 
> situation could have just as easily been the case in Access.  Access 
> doesn't prevent poorly designed fields, nor does Access have any wizards 
> that will automatically split data out into multiple fields.
> 
> FM's SQL support definitely is not as robust as it is in Access.  But 
> that doesn't mean that doing what this woman wanted to do is any more 
> difficult to do in FileMaker then in Access or in SQL Server.  Based on 
> why she was in her predicment in the first place, I doubt she knows SQL. 
>  And for a newbie walking opening both Access and FileMaker for the 
> first time, I am guessing that FM would be quicker to pick up.  I don't 
> doubt that Access is more powerful, but I think FMP is more intuitive.
> 
>> To me, it seems you've got it exactly backwards here -- FM is the
>> one that is primarily and end-user with meager scripting support.
>> Everything in it is designed to be easy for point and clickers (this
>> is not a bad thing, of course). Access started out with the same
>> goals but is not as end-user-friendly, from what I understand about
>> it (I downloaded the FM7 demo a while back but never got around to
>> trying it out).
>> But Access provides power and control at the highest level to any
>> programmer who wants to use it. 
> 
> 
> Again, there is no question that Access is more flexible and powerful in 
> its scripting.  I believe that Access can do absolutely anything if a VB 
> programmer gets his/her hands on it.  But that might be a steep learning 
> curve for someone who just wants to build a database.  Whenever I've 
> tried building anything more than a basic Access solution, I have run 
> into the obstacle of needing to know some VB.

At some point, Access flexes itself right out of a job... I mean if you 
have an enterprise rdbms at the backend, and your are planning to need 
extensive VB expertise at the front I start to question why even bother 
with Access at all?

Just fire up Visual Studio and build the front end in .NET in VB/C#, and 
free yourself from licensing access.
0
42
6/24/2004 4:28:39 AM
"Lyle Fairfield" <MissingAddress@Invalid.Com> wrote in message
news:Xns9511D81CB97C2FFDBA@130.133.1.4...
> "Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in
> news:zalCc.860394$oR5.10370@pd7tw3no:
>
> > You are confusing VBS (which is a windows scripting language, and quite
> > limited at that).
>
> quite limited?
>

Actually, VBS as not that limited, but the IDE as general rule is (and, I
think there is a IDE you CAN use for VBS?).

So, a better choice of words is more limited then VBA. I comes down to
things like linking (references), and data typing (both of which VBS lacks).
(with all the new modern programming languages these days, lack of typing
might be consider a "feature" and not lack of!).

I should not take aim at VBS, since OFTEN people state that windows does NOT
have a good scripting language, and when you compare windows scripting to
unix base systems, VBS certainly holds it own (in fact, a lot of windows
admins are NOT that good at VBS, and often this results in people thinking
that the scripting ability of windows is weak, where as the real problem is
that scripting language is TOO complex for a lot of admins).

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/24/2004 6:20:29 AM
"42" <42@nospam.com> wrote in message
news:x0rCc.829863$Pk3.545910@pd7tw1no...
>
> I would think it would be far more confusing to the issue to try and
> compare FM to Access + Oracle or another enterprise RDBMS backend don't
you?

I agree. However, what *is* important here is not that we go out and
purchase sql server, or Oracle, but what do you get on the cd or original
package is at issue here.

It is NOT widely know that for the LAST 3 versions of ms-access, ms-access
is capable of operating as  a 100% native client to server application.
Further, it is MOST important to note that both the server part, and client
part have been included for the LAST three versions. So, what is much at
issue here is that most (if not all) of these so called comparisons of
ms-access performance are from a very old version of ms-access, and COMPLETE
IGNORE the client to server version of ms-access. Further, the server
portion IS included. It is NOT like we have to go out and purchase
sql-server, or purchase oracle here.

So, my point here is It would be VERY silly (or simply dishonest) to compare
ms-access in a file server mode to FileMaker in a client-to server mode. I
suppose, this kind comparison WOULD BE fair if you would taking about the
old version of ms-access. I mean, access 97 did NOT include a server based
engine as part of the install. So, I would say that old comparisons are
fair..after all, if the product don't come with a server engine..who's fault
is that!! So, I thus say that these old comparisons were fair. So, when you
look at ms-access 4 versions ago (access 97), it DID NOT come with a client
to server version on the cd. Of course, access97 certainly could connect to
sql server via ODBC, but out of the box, we did NOT get a server engine, nor
did we get a OLEdb connection ability).

The last 3 versions of access have this ability, and HAVE shipped with a
server based engine. Lets not be silly, and go back 4 versions ago to make
comparisons (that is VERY LONG time ago folks!). This is just an issue of
honesty, and ones knowledge of the products. To ignore the server based
engine that ships with ms-access for the last 3 versions I think is very
un-fair at best, and at worst..simply dishonest.

I am not asking one to all of a sudden bring Oracle into this..but at least
look at the server based engine on the cd. What is truly great about his
engine that it is 100% compatible with sql sever, and even more interesting
is that you can use ALL of the SAME sql corporate Enterprise Tools to work
with this little engine. At the end of the day, this means you get to learn,
an use sql server without having to purchase it. You also get triggers, and
the server based t-sql langue with that engine included on the ms-access cd.
This is great thing...as one can clearly argue that leaning sql server is a
marketable skill, and this skill allows one to scale the ms-access
application to any number of users you please (what server do you want to
learn when your application gets too large and outgrows the one on the
office cd?).

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/24/2004 6:49:40 AM
> > In today's world, if it doesn't support SQL, I'm sorry, but it's not
> > really a serious database product. 


Hmm,  why don't they provide SQL functionality? That's a point I
missed in the original post.
I thought version 7 would have tackled that.

FM camp: Now forget about VBA, is it possible to implement in FM a
stack (nested) query, says 3 or 4 levels (that means the retrieval
criteria is so complex that you need to write an SQL, then another SQL
to extract data from the first one, then a third SQL to get the data
from the second one, and so on ....) ?

NB
0
nickbose
6/24/2004 7:20:26 AM
> VB. But then again, 4D has an extensive language too. I would sooner use 
> 4D than Access if I wanted a programming-based database. And 4D is cross 
> platform too. I really don't see the draw to Access, other than people 

I heard of 4thD before but never had time to take a long look.
Has anyone here tried it? Please give some comments too, particularly
in comparison to the more popular Access and FM.

Thks

NB
0
nickbose
6/24/2004 7:39:51 AM
Albert D. Kallal wrote:
> "42" <42@nospam.com> wrote in message
> news:x0rCc.829863$Pk3.545910@pd7tw1no...
> 
>>I would think it would be far more confusing to the issue to try and
>>compare FM to Access + Oracle or another enterprise RDBMS backend don't
> 
> you?
> 
> I agree. However, what *is* important here is not that we go out and
> purchase sql server, or Oracle, but what do you get on the cd or original
> package is at issue here.

Fair enough.

> It is NOT widely know that for the LAST 3 versions of ms-access, ms-access
> is capable of operating as  a 100% native client to server application.
<snip>

If MSDE isn't well known its because MS has done a poor job of marketing it.

> 
> I am not asking one to all of a sudden bring Oracle into this..but at least
> look at the server based engine on the cd. What is truly great about his
> engine that it is 100% compatible with sql sever, and even more interesting
> is that you can use ALL of the SAME sql corporate Enterprise Tools to work
> with this little engine.

Its also worth pointing out that installing and using MSDE is not as end 
user friendly as JET, nor is MSDE the default (in fact its not even 
usually installed.) Nor is there much documentation for MSDE readily 
available... (at least not with Office XP)

And worst of all, JET solutions do not port to MSDE as transparently as 
we could like.

If we're going to compare FM to Access+MSDE I can live with that, but 
then FM gains a considerable edge when it comes to deployment and an 
even bigger edge in ease of use, not to mention that there is no 
migration required to scale a single user to a multiuser version. With 
Access you have to think ahead and target MSDE at the outset... and 
start eating extra admin and deployment headaches right from day one.

> At the end of the day, this means you get to learn,
> an use sql server without having to purchase it.
> You also get triggers, and
> the server based t-sql langue with that engine included on the ms-access cd.
> This is great thing...as one can clearly argue that leaning sql server is a
> marketable skill,

Learning SQL is a marketable skill. Learning SQL Server is also 
marketable but the extra specificness doesn't buy you that much, 
especially if you only have practical experience with 'small scale' 
solutions.

Besides mySQL vs SQL Server is not that big of a deal... a bright lad 
will be able to make the transition pretty quickly.

> and this skill allows one to scale the ms-access
> application to any number of users you please (what server do you want to
> learn when your application gets too large and outgrows the one on the
> office cd?).

Ah... there's the rub.

A filemaker solution would take much longer to outgrow than the one on 
your office CD.

Besides I would think its a poor business strategy to needlessly marry 
my application to Microsoft enterprise servers. If I'm going to write 
against client/server SQL backend then I'd prefer to adhere to SQL 
standards as much as possible, to make targeting MySQL, SQL Server, 
Oracle, etc... an option. As a software vendor it makes sense, and as an 
internal system it makes sense.
0
42
6/24/2004 8:35:48 AM
NB wrote:

>>>In today's world, if it doesn't support SQL, I'm sorry, but it's not
>>>really a serious database product. 
> 
> 
> 
> Hmm,  why don't they provide SQL functionality? That's a point I
> missed in the original post.
> I thought version 7 would have tackled that.
> 
> FM camp: Now forget about VBA, is it possible to implement in FM a
> stack (nested) query, says 3 or 4 levels (that means the retrieval
> criteria is so complex that you need to write an SQL, then another SQL
> to extract data from the first one, then a third SQL to get the data
> from the second one, and so on ....) ?

I'm skeptical that any final dataset that you would want to extract with 
SQL couldn't also be accomplished in FM in some way.
0
42
6/24/2004 8:55:36 AM
"Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in
news:NouCc.866336$oR5.316889@pd7tw3no: 

> <snips> (in fact, a
> lot of windows admins are NOT that good at VBS, and often this results
> in people thinking that the scripting ability of windows is weak, where
> as the real problem is that scripting language is TOO complex for a lot
> of admins). 

!

-- 
Lyle
(for e-mail refer to http://ffdba.com/)
0
Lyle
6/24/2004 9:35:55 AM
"James L. Ryan" <taliesinsoft@mac.com> wrote in message
news:0001HW.BCFFBF1E007C44B9F03055B0@news.prodigy.net...
> On Wed, 23 Jun 2004 22:35:05 -0500, K&V P wrote
> (in article <JZrCc.874213$Ig.666717@pd7tw2no>):
>
> > "640k should be enough for anybody."
> >                   - - Bill Gates, 1981
>
> Back in 1978 I was taken on a tour of the computer facilities of what was
> then perhaps the nation's foremost purveyor of computer based econometric
> information. Part of the facility was a large room, I'd say perhaps 40 by
80
> feet, which contained nothing but a veritable sea of Burroughs 40 inch
> platter hard disk drives. I commented to my host that I'd never in my then
20
> years of computing seen so much disk storage in one location, and I asked
how
> much storage there was. The answer.....    "just over a gigabyte!"
>
> I can also remember paying almost $5,000 for a hard drive for my Apple
III.

What were you working on in 1958,  Great Gramps?



0
rkc
6/24/2004 11:16:18 AM
42 wrote:


> 
> I'm skeptical that any final dataset that you would want to extract with 
> SQL couldn't also be accomplished in FM in some way.

FM does support nested queries.
0
Kevin
6/24/2004 12:57:23 PM
David W. Fenton wrote:


> 
> I've just recently observed a discussion in another online forum
> where a FM user was pulling her hair out trying to break down a
> poorly designed field into multiple fields (several independent
> pieces of data were packed into the single field). She had lots of
> trouble copying the data into the new fields. 

Lack of knowledge of the product and poor database design can be 
accomplished just as easily on any database. It doesn't say a thing 
about the product itself. I've rescued people's data from poor design 
several times without trouble.

> In today's world, if it doesn't support SQL, I'm sorry, but it's not
> really a serious database product. 

Firstly, the "I'm sorry" is a bit condescending, don't you think? 
Secondly, FM does support SQL queries, but that's irrelevant. SQL is 
underlying technology that the end users never see. To claim a serious 
database product requires it is petty and arbitrary. Can I claim a 
serious DB needs to run on UNIX? How about cross platform? My claims are 
just as valid as yours.

Why isn't Access cross platform? If I want cross platform and language 
programmability, shouldn't I choose 4D over Access. I really don't see 
the point of using Access unless people already have it on their PCs.
0
Kevin
6/24/2004 1:02:14 PM
"Kevin Hayes" <me@here.com> wrote in message
news:cbeiuv$35o$3@zcars0v6.ca.nortel.com...
> 42 wrote:
>
>
> >
> > I'm skeptical that any final dataset that you would want to extract with
> > SQL couldn't also be accomplished in FM in some way.
>
> FM does support nested queries.

Does that mean he is wrong?


0
Glenn
6/24/2004 1:48:41 PM
"Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in message
news:10dlmtraq5ml970@corp.supernews.com...
> "Kevin Hayes" <me@here.com> wrote in message
> news:cbeiuv$35o$3@zcars0v6.ca.nortel.com...
> > 42 wrote:
> >
> >
> > >
> > > I'm skeptical that any final dataset that you would want to extract
with
> > > SQL couldn't also be accomplished in FM in some way.
> >
> > FM does support nested queries.
>
> Does that mean he is wrong?
>

Or, now that I read it again, are you on his side?


0
Glenn
6/24/2004 1:50:15 PM
Glenn Schwandt wrote:

>>
>>Does that mean he is wrong?
>>
> 
> 
> Or, now that I read it again, are you on his side?
> 

Heh heh, I'm not on a "side". This isn't a battle or contest. At least, 
I'm not treating it as such ;-) I'm just confirming that you can do 
nested queries in FM in case other readers here are unsure.

I haven't tried it using SQL so I can't confirm or deny that part, but 
it can be accomplished by a series of searches on found sets - this can 
easily be scripted too.
0
Kevin
6/24/2004 3:38:47 PM
"Kevin Hayes" <me@here.com> wrote in message
news:cbesdi$ebr$1@zcars0v6.ca.nortel.com...
> Glenn Schwandt wrote:
>
> >>
> >>Does that mean he is wrong?
> >>
> >
> >
> > Or, now that I read it again, are you on his side?
> >
>
> Heh heh, I'm not on a "side". This isn't a battle or contest. At least,
> I'm not treating it as such ;-) I'm just confirming that you can do
> nested queries in FM in case other readers here are unsure.
>
> I haven't tried it using SQL so I can't confirm or deny that part, but
> it can be accomplished by a series of searches on found sets - this can
> easily be scripted too.

I guess what I meant was whether you agreed with "42" or not on this
particular part of the discussion.  I am also not interested in taking sides
in the overall discussion (I don't have the necessary Access experience).

I would certainly be interested in seeing any complex query that could not
be duplicated in FileMaker.  Maybe "NB" will follow up with an example of
his "stack (nested) query" that we could try to implement in FileMaker.


0
Glenn
6/24/2004 4:01:47 PM
NB <nickbose@softhome.net> wrote:

> Hmm,  why don't they provide SQL functionality? That's a point I
> missed in the original post.
> I thought version 7 would have tackled that.
> 
> FM camp: Now forget about VBA, is it possible to implement in FM a
> stack (nested) query, says 3 or 4 levels (that means the retrieval
> criteria is so complex that you need to write an SQL, then another SQL
> to extract data from the first one, then a third SQL to get the data
> from the second one, and so on ....) ?

FM (versions 5 & up) does indeed provide SQL functionality. Any SQL
query you can write can be built in FM, and there's no reason you
couldn't write a nested query, if you know how.

I've only done very simple SQL queries in FM to pull data out of
(MS-SQL) tables, and haven't ever needed to push data back, but that's
also possible.  I'd say one's ability to write such queries would be
limited by one's SQL skills, rather than by FM.  One writes the query
into a global text field (usually with a script, using parameters
entered in fields) and then implements the Send SQL script step to
execute it.

Lynn Allen
www.semiotics.com


FM 7 Tip of the Week: Field Behavior allows developers to choose entry
options like permitting entry into a field in Find mode but not Browse,
and whether a field is exited by Tab, Enter or Return keys (or all
three). No more scripts to "protect" fields!  
 
0
lynn
6/24/2004 5:24:38 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dkff221gaqof3@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> I've just recently observed a discussion in another online forum
>> where a FM user was pulling her hair out trying to break down a
>> poorly designed field into multiple fields (several independent
>> pieces of data were packed into the single field). She had lots
>> of trouble copying the data into the new fields. 
>> 
>> In today's world, if it doesn't support SQL, I'm sorry, but it's
>> not really a serious database product. 
> 
> Well, it's a shame that the user was pulling her hair out.  But
> her situation could have just as easily been the case in Access. 
> Access doesn't prevent poorly designed fields, nor does Access
> have any wizards that will automatically split data out into
> multiple fields. 

No it doesn't, but anybody who knows SQL could have given here the
SQL to copy the data to the new fields. With FM, there weren't
enough people around who had a clue about how to do it. And several
people made suggestions, but for whatever reason, she couldn't make
it work. 

And the problem wasn't decomposing the incorrect field. That was
easily done with FM's string functions, which someone posted at the
beginning of the discussion. It was the simply process of copying
the results to new fields that stumped her. 

> FM's SQL support definitely is not as robust as it is in Access. 
> But that doesn't mean that doing what this woman wanted to do is
> any more difficult to do in FileMaker then in Access or in SQL
> Server.  Based on why she was in her predicment in the first
> place, I doubt she knows SQL. 

Doesn't matter if she does -- SQL would have increased the number of
people who could explain to her how to copy the data to the new
fields. 

>   And for a newbie walking opening both Access and FileMaker for
>   the 
> first time, I am guessing that FM would be quicker to pick up.  I
> don't doubt that Access is more powerful, but I think FMP is more
> intuitive. 

This is why I dispute the characterization by someone in this thread
of FM as a programmer's tool and Access as an end-user tool. Both
products serve both audiences. But for programmers, SQL is
invaluable, and makes it a lot easier for someone with database
experience on other platforms to build applications quickly in
Access. 

And you don't need to know SQL to make Access work -- it writes the
SQL for you. 

But it offers the possibility of editing the SQL by hand (there are
a number of things that aren't doable in the QBE, such as UNIONs). 

>> To me, it seems you've got it exactly backwards here -- FM is the
>> one that is primarily and end-user with meager scripting support.
>> Everything in it is designed to be easy for point and clickers
>> (this is not a bad thing, of course). Access started out with the
>> same goals but is not as end-user-friendly, from what I
>> understand about it (I downloaded the FM7 demo a while back but
>> never got around to trying it out). 
>> 
>> But Access provides power and control at the highest level to any
>> programmer who wants to use it. 
> 
> Again, there is no question that Access is more flexible and
> powerful in its scripting.  I believe that Access can do
> absolutely anything if a VB programmer gets his/her hands on it. 
> But that might be a steep learning curve for someone who just
> wants to build a database. . . .

I recently talked to a Mac user who at one time was a PC user who
developed in dBase (because he needed a database for storing and
retrieving the data for his dissertation), and who had to use Access
in his current job. He says FileMaker is much better from his point
of view. So, yes, I believe that FM makes certain things easier. 

But the complexities of all the things that were required for the
poor woman who just wanted to decompose and copy a field into new
fields made it look like once you get past basic stuff, FM makes
things harder. 

> . . . Whenever I've tried building anything
> more than a basic Access solution, I have run into the obstacle of
> needing to know some VB.  While FileMaker can't itself be
> controlled by VB, it does have some ActiveX controls and it can
> also incorporate any VB into its scripts to control other 
> applications.  This makes it simple enough to integrate data with
> other apps.

FM can do VB? Wow! That's interesting, and quite surprising. I'll
have to look more closely at it, then, as that's a whole different
ballgame. 

> Don't get me wrong -- there are certainly some features that I'd
> love to see built in to FileMaker, just as I'm sure there are
> things you'd like to see built into Access.  But lacking those
> desired features doesn't inhibit FileMaker developers from
> building what they want to build.  And with very few exceptions,
> there is little that Access can do that FMP can't.  I would argue,
> though, that someone with equal knowledge of both apps might be
> able to build a solution more quickly in FMP than they could in
> Access. 

Fair enough.

It just looked to me like relatively simple alterations to an
existing table and existing form layouts were much harder in FM than
the corresponding alterations would have been in Access. 

I'll have to try out the download, as I truly am interested in
getting away from Access before MS .NETs it into oblivion. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 5:27:04 PM
42 <42@nospam.com> wrote in news:XLsCc.830418$Pk3.571850@pd7tw1no:

> At some point, Access flexes itself right out of a job... I mean
> if you have an enterprise rdbms at the backend, and your are
> planning to need extensive VB expertise at the front I start to
> question why even bother with Access at all?
> 
> Just fire up Visual Studio and build the front end in .NET in
> VB/C#, and free yourself from licensing access.

Well, that's a perfectly good answer if you've got a budget two to
three times that of what was allocated for the Access project. 

That is, Access is much faster for building all the things you need
in the front end to a database application than tools that are not
designed for that purpose. 

And only someone who has never used Access to build a real
application would imagine that switching to platforms that aren't
designed for building database front ends would make sense. Just
look at the event model of an Access form, and you immediately can
see why it's superior to the generic forms you can build in any
other language. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 5:29:29 PM
Kevin Hayes <me@here.com> wrote in
news:cbej81$3gp$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:

>> I've just recently observed a discussion in another online forum
>> where a FM user was pulling her hair out trying to break down a
>> poorly designed field into multiple fields (several independent
>> pieces of data were packed into the single field). She had lots
>> of trouble copying the data into the new fields. 
> 
> Lack of knowledge of the product and poor database design can be 
> accomplished just as easily on any database. It doesn't say a
> thing about the product itself. I've rescued people's data from
> poor design several times without trouble.

I guess I didn't make it clear: the part that suprised me was not
that she made the original design error (lots of people make that
error), but that it was so frigging complicated to copy the results
of string functions into the new fields. And that the methods
suggested by other FM users didn't seem to work for her. 

>> In today's world, if it doesn't support SQL, I'm sorry, but it's
>> not really a serious database product. 
> 
> Firstly, the "I'm sorry" is a bit condescending, don't you think? 

Fully intended. SQL is the lingua franca of all databases,
worldwide. Not supporting it makes the product far, far less easy to
use for people who already have database experience. 

Maybe FM is really easy for people who know nothing about databases,
and that's a really good thing, but if people who *do* know
databases have to learn everything from scratch to use it (because
it doesn't support industry standards), then it is less suitable as
a database development platform for anyone but the novice. 

> Secondly, FM does support SQL queries, but that's irrelevant. SQL
> is underlying technology that the end users never see. To claim a
> serious database product requires it is petty and arbitrary. Can I
> claim a serious DB needs to run on UNIX? How about cross platform?
> My claims are just as valid as yours.

A database product that doesn't support SQL is like a web browser
that doesn't support HTML. 

And with SQL, the problem this poor woman had with copying data to a
new field would have been trivial. There would have been dozens of
people who've never used FM who could have given her the SQL to copy
the data. 

> Why isn't Access cross platform? If I want cross platform and
> language programmability, shouldn't I choose 4D over Access. I
> really don't see the point of using Access unless people already
> have it on their PCs. 

I don't know what you should choose. Obviously Access is not and
never will be cross-platform. That's one of the things I don't like
about it. I think part of the reason for it is that the multi-user
capabilities of Access are intimately connected to the way the
Windows file systems work (I would, for instance, never recommend 
storing MDBs on a SAMBA or NETWARE server). 

The fact that FM is cross-platform is the only reason I've
downloaded it to evaluate. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 5:36:18 PM
"K&V P" <random_characters@shaw.ca.invalid> wrote in
news:JZrCc.874213$Ig.666717@pd7tw2no: 

> "David W. Fenton"  wrote...
>> 4GBs in a single field? Why would anyone need that?
> 
> 
> "640k should be enough for anybody."
>                   - - Bill Gates, 1981
> 
> Maybe you're too young to remember where that one got us?

I didn't say no one would need it. I asked why.

Please explain how one would use a 4GB field.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 5:36:56 PM
42 <42@nospam.com> wrote in news:EnwCc.877562$Ig.613315@pd7tw2no:

> If we're going to compare FM to Access+MSDE I can live with that,
> but then FM gains a considerable edge when it comes to deployment
> and an even bigger edge in ease of use, not to mention that there
> is no migration required to scale a single user to a multiuser
> version. With Access you have to think ahead and target MSDE at
> the outset... and start eating extra admin and deployment
> headaches right from day one. 

Sorry, but everyone is avoiding answering the original question:

Where does FM perform better as compared to Access?

In what scenarios?

In what kind of operations?

Ease of deployment is simply not relevant to that question.

The allegation was that FM is faster than Access for retrieving
data. I want some factual information to support that allegation. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 5:40:52 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dkhiopi41gb35@corp.supernews.com: 

> David W. Fenton wrote:
>>>(Pete Cresswell) wrote:
>>>
>>>>>Overall, FM7 adopts many of the good features of Access.
>>>
>>>>Can you split the app into back end and front end?   
>>>
>>>For the most part, yes.  Certainly as well as you can in Access,
>>>if not better.
>> 
>> Please explain what's better about FM's splitting of the app.
> 
> To be fair, I haven't opened Access in more than a year.  I am
> looking at Access 7.  I'm sure you'll correct me if I'm wrong or
> if things have changed.

Access is Access95, released in early 1996. It was the most buggy
version of Access ever released (though A2K runs it a close second).
It was quickly replaced by Access97, which added very few new
features and mostly fixed the bugs. Office95 was an important
milestone release for Microsoft, as it was not just the first 32-bit
version of the full Office suite (there were 32-bit NT versions of
Excel and Word before, but not of the other Office programs), but
also the first to implement VBA suite-wide, but it was very buggy
and unreliable. 

And, of course, Access 95 is far from the current release. There
have been major architectural changes and the addition of a huge
number of features designed for making it easier to build
client/server apps with Access. 

> Like FileMaker, Access files combine multiple data tables, forms,
> macros and other objects into a single file.  But it seems that
> Access can only have one file open at a time, whereas FMP can have
> multiple files open. 

Access can have only one MDB open in the front end. It can connect
to any number of back end databases, and can load both forms and
data from those back ends (loading forms from a different MDB is a
little trickier, of course, but it's how all the Access wizards are
implemented). 

>   This means that you can have an interface file separate from
>   your data 
> file.  You can set up seamless references and relationships
> between the multiple tables in the multiple files.  Your interface
> file, in fact, doesn't even need to have any data tables defined.

This is different from Access exactly how?

All of my applications are installed with a front-end MDB connecting
to two or more back ends (one with the shared data, on the server,
and one on the client for temp data). 

> > And, as Albert recommends, don't confuse the issue by comparing
> > FM with its server-side database engine to Access with just Jet.
> 
> I'm not familiar with Jet or whatever you're suggesting. . . .

Jet is Access's native data engine. An MDB is the base Jet data
file. An MDB created in Access has custom properties that are
accessible when it is opened by Access. Data tables and queries are
pure Jet objects, though, and can be accessed by the Jet data engine
without needing Access. When an MDB file is used to store data for
driving a web page, for instance, that is the Jet database engine
doing the work, even if the Access UI was used to create the MDB
file. 

> . . . But I
> think what we are really comparing here are the base applications
> on their default servers. . . .

Jet isn't a server-based database engine. And that's why I raised
the issue -- people are always comparing the wrong things because
they don't adequately understand the depth of possibilities and
capabilities offered by Access. 

> . . . I am thinking about hardware/software
> costs, development/setup time, cross-platform capability,
> intuitive user interface and (from what I'm told; I've admittedly
> no firsthand experience with this) server/client communication
> speed...Filemaker would be the hands-up winner. . . 

I'd like some specifics for these assertions in regard to
client/server performance. If you're comparing to Access with a Jet
back end (i.e., an MDB file), then you're comparing apples and
oranges, as Jet is by definition not client/server. The proper point
of comparison is Access with MSDE/SQL Server for the back end. 

And I'd be interested in specifics about what kinds of operations in
FM's client/server configuration are faster than the corresponding
operation in an Access client/server configuration. 

> . . . Based on
> potential programming power and potential configurations, I'll
> give it to Access.  Different applications, different markets,
> different user base 

Cross platform is the only unambiguous win for FM, in my opinion. In
regard to cost of hardware/software, I can't see how there is a
difference. FM is not cheap, neither is Access. On the PC side, they
can run on the exact same hardware. 

As to development/setup time, I can't see how we could compare,
because I don't know what we are comparing. My bet is that given a
set of clear requirements I could produce the Access application
just as quickly as you could produce the FM application. 

As to "intuitive user interface," that's very subjective, and I
think "intutiveness" is over-rated and mostly a huge scam. There is
nothing intuitive about using a mouse to click on things (remember
Scotty talking into the mouse as a microphone in Star Trek IV?) --
you have to understand the underlying metaphors behind the
application for it to start to feel transparent. Maybe FM is more
Mac-like in its approach to UI. If that is so, that might be why Mac
users do better with it than when they try Access on Windows. 

So, I think it really comes down to performance, and on that
subject, you admit you have no information at all. 

Let's talk about some scenarios. Let's try out some things. I've got
the demo so I can try things out and see how they compare on my
system (though I don't have a server to do client/server testing). 

I'm truly interested, because I don't like being locked into
Microsoft's agenda for Access, which has clearly been at odds with
my own since the release of A2K. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 6:00:03 PM
42 <42@nospam.com> wrote in news:MYqCc.864558$oR5.825340@pd7tw3no:

> Lyle Fairfield wrote:
> 
>> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
>> news:40DA2BB7.2030909@antispahm.fmprosolutions.com:
>> 
>> 
>>>(Pete Cresswell) wrote:
>>>
>>>>>Overall, FM7 adopts many of the good features of Access.
>>>
>>>>Can you split the app into back end and front end?   
>>>
>>>For the most part, yes.  Certainly as well as you can in Access,
>>>if not better.
>> 
>> 
>> How do you know how well Pete can ... or do you mean ... as well
>> as Howard can ... and how "well" is that? 
> 
> You can put the database tables in one or more files, and put the
> front end layouts and scripts in one or more different files. You
> can have multiple front ends accessing the same files.

Yes, that's exactly what you can do in Access.

Can FileMaker do the same?

>>... and in what way might it be "better"?
> 
> It might be better if it provided more tools to assist the
> user/develop in maintaining that boundary.

What boundary?

What are you talking about?

The standard configuration for an Access multi-user application is
an MDB file with the forms, reports and so forth on the client
workstation and a shared MDB for data on the file server if you're
using Jet to store the data, and if not, then a server database of
your choice to store the data. 

I usually have a second temp MDB on the workstation for temporary
data. 

A few apps I've shipped have also included utility databases along
with the front end MDB, which are basically used as libraries of
code in my app, but can also include forms and reports. The wizards
in Access itself work exactly that way -- they are in MDE files and
when you run them, the forms that display onscreen are loaded from
that MDE in the current Access session. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 6:03:00 PM
"David W. Fenton" wrote...
> "K&V P" wrote:
>
> > "David W. Fenton"  wrote...
> >> 4GBs in a single field? Why would anyone need that?
> > "640k should be enough for anybody."
> >                   - - Bill Gates, 1981
> > Maybe you're too young to remember where that one got us?
> I didn't say no one would need it. I asked why.
> Please explain how one would use a 4GB field.

And neither did I, say that anyone would have a use for it (today).

What I intentionally implied is that it is short-sighted to criticize something
for being capable of more than is needed today.

If I compile a solution that permits storage of video files internally (for
security), and ten years from now someone decides they want to use that solution
to store a variety of 6 hour instructional videos on an optical storage Welton
Cube that holds 4 terabytes of data, maybe they can. Maybe they won't have to go
looking for someone to update it to newer technology, Which, no matter how many
new bells and whistles it has, there-by renders their existing body of data
useless.

7 years ago, I spent nearly 20 hours extracting data from a DOS database for a
local church because they needed to switch away from the custom solution they
were using due to space limitations imposed by Mr. Gates.

There are enough limitations around us to make it absurd to imply criticism of
something for having an unusually large limitation on something.

That's without even getting into the philosophical fallacy of turning an
un-required positive into a negative in an argument.

Kent


0
K
6/24/2004 6:11:10 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbej81$3gp$1@zcars0v6.ca.nortel.com: 
> 
> I guess I didn't make it clear: the part that suprised me was not
> that she made the original design error (lots of people make that
> error), but that it was so frigging complicated to copy the results
> of string functions into the new fields. And that the methods
> suggested by other FM users didn't seem to work for her. 

It is very easy to do what you described. It is not FMs fault her and 
her coworkers are ignorant of the product. A simple script would do it. 
Or, as you said, an SQL statement.

>>>In today's world, if it doesn't support SQL, I'm sorry, but it's
>>>not really a serious database product. 
>>
>>Firstly, the "I'm sorry" is a bit condescending, don't you think? 
> 
> 
> Fully intended. SQL is the lingua franca of all databases,
> worldwide. Not supporting it makes the product far, far less easy to
> use for people who already have database experience. 

I think you are missing the point of the product. It's a product to make 
databases for end-users with little dbms experience. It does its job 
very well, thank you.

> Maybe FM is really easy for people who know nothing about databases,
> and that's a really good thing, but if people who *do* know
> databases have to learn everything from scratch to use it (because
> it doesn't support industry standards), then it is less suitable as
> a database development platform for anyone but the novice.

No, it simply means developers have to drop the arrogance and realize 
it's a different tool. Learning new ways of doing things is a good way. 
If FM worked like every other DB tool, then what is the point of using it?

> A database product that doesn't support SQL is like a web browser
> that doesn't support HTML. 

That is BS. It is more like saying a book is no good because the author 
didn't use Microsoft Word to write it. The purpose of a web browser is 
to display HTML. The purpose of a databsae system is to develop 
solutions to hand users' data. FM does this very well. The underlying 
technology is irrelevant. Moot point anyway, as FM does have SQL.

> And with SQL, the problem this poor woman had with copying data to a
> new field would have been trivial. There would have been dozens of
> people who've never used FM who could have given her the SQL to copy
> the data. 

FM does have SQL. Either her or her coworkers didn't know that. As I 
stated in a previous post in this thread, FM often gets blamed because 
people don't know the capabilities of the product.

0
Kevin
6/24/2004 6:13:26 PM
David W. Fenton wrote:


> Please explain how one would use a 4GB field.

To store binary data.
- archives of image sets or other large files
- boot disk images for lab computers
- video footage
0
Kevin
6/24/2004 6:17:23 PM
David W. Fenton wrote:

> Access can have only one MDB open in the front end. It can connect
> to any number of back end databases, and can load both forms and
> data from those back ends (loading forms from a different MDB is a
> little trickier, of course, but it's how all the Access wizards are
> implemented). 

Really? So if I have multiple unrelated local database solutions (not 
client-server setups), I can only have one open at a given time? If so, 
then that's a pretty bad limitation.
0
Kevin
6/24/2004 6:21:35 PM
David W. Fenton wrote:

> Let's talk about some scenarios. Let's try out some things. I've got
> the demo so I can try things out and see how they compare on my
> system (though I don't have a server to do client/server testing). 

I wish I could be more specific, but I don't have the current version of 
Access to test against.  Some areas where I would invite a comparison:

1) search on multiple criteria over a million records (either scripted 
or query by example;
2) sort a million records on multiple fields;
3) access a database over a WAN, with nothing on the client except for 
the app itself (i.e. no MDB or FP7 files);

These tasks (searching and sorting) would seem to be the most used 
features, and the easiest to strip the apps to their bare bones (without 
relying on the efficiency of different scripting techniques).  And these 
are features where I feel FM7 is strong.

Any other ideas from an Access perspective?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/24/2004 6:35:03 PM
"Kevin Hayes" <me@here.com> wrote in message
news:cbf5uq$p69$1@zcars0v6.ca.nortel.com...
> David W. Fenton wrote:
>
> > Access can have only one MDB open in the front end. It can connect
> > to any number of back end databases, and can load both forms and
> > data from those back ends (loading forms from a different MDB is a
> > little trickier, of course, but it's how all the Access wizards are
> > implemented).
>
> Really? So if I have multiple unrelated local database solutions (not
> client-server setups), I can only have one open at a given time? If so,
> then that's a pretty bad limitation.

You can open multiple "instances" of Access. Each instance would be running
a single "application file".  There are ways to link files or use
automation so that you can be in an instance of "file A" and have it open a
form or run code stored in "file B".


-- 
I don't check the Email account attached
to this message.     Send instead to...
RBrandt    at       Hunter      dot      com


0
Rick
6/24/2004 6:48:49 PM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:EnwCc.877562$Ig.613315@pd7tw2no:
> 
> 
>>If we're going to compare FM to Access+MSDE I can live with that,
>>but then FM gains a considerable edge when it comes to deployment
>>and an even bigger edge in ease of use, not to mention that there
>>is no migration required to scale a single user to a multiuser
>>version. With Access you have to think ahead and target MSDE at
>>the outset... and start eating extra admin and deployment
>>headaches right from day one. 
> 
> 
> Sorry, but everyone is avoiding answering the original question:
> 
> Where does FM perform better as compared to Access?

As in you want a specific query against a specific database in a 
particular network configuration?

If you can find a series of recent benchmarks I'd *love* to see them.

> In what scenarios?

Faster development, easier to use, easier to deploy. Those are gimmes. 
Actual performance of a given query or sort or something, I can't say 
which is faster when, both are quite good, and they can both be coded 
badly enough to be brutally slow.

Filemaker also scales up much higher than Access in the number of 
simultaneous users while retaining its speed, unless you put a SQL 
Server backend in... but then that's not really access anymore.

> In what kind of operations?
> 
> Ease of deployment is simply not relevant to that question.

Ah, and here I thought someone asked where the two products various 
strengths lie.

> The allegation was that FM is faster than Access for retrieving
> data. I want some factual information to support that allegation. 
> 

Maybe I missed it, but I haven't seen anyone actually allege that. There 
are no reliable benchmarks. And everybody knows you can make either 
database win a benchmark by designing the other one badly enough.
0
42
6/24/2004 6:53:03 PM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:MYqCc.864558$oR5.825340@pd7tw3no:
> 
> 
>>Lyle Fairfield wrote:
>>
>>
>>>Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
>>>news:40DA2BB7.2030909@antispahm.fmprosolutions.com:
>>>
>>>
>>>
>>>>(Pete Cresswell) wrote:
>>>>
>>>>
>>>>>>Overall, FM7 adopts many of the good features of Access.
>>>>
>>>>>Can you split the app into back end and front end?   
>>>>
>>>>For the most part, yes.  Certainly as well as you can in Access,
>>>>if not better.
>>>
>>>
>>>How do you know how well Pete can ... or do you mean ... as well
>>>as Howard can ... and how "well" is that? 
>>
>>You can put the database tables in one or more files, and put the
>>front end layouts and scripts in one or more different files. You
>>can have multiple front ends accessing the same files.
> 
> 
> Yes, that's exactly what you can do in Access.

> Can FileMaker do the same?

Actually I *was* talking about FM.

> 
>>>... and in what way might it be "better"?
>>
>>It might be better if it provided more tools to assist the
>>user/develop in maintaining that boundary.
> 
> 
> What boundary?

The boundary between application and data.
> 
> What are you talking about?

FM.

> The standard configuration for an Access multi-user application is
> an MDB file with the forms, reports and so forth on the client
> workstation and a shared MDB for data on the file server if you're
> using Jet to store the data, and if not, then a server database of
> your choice to store the data. 

The standard solution for FM multiuser apps is to host everything on the 
server. Until v7 the access way you describe wasn't really an option. I 
wonder how well it would work in v7?

(Normally hosting everything on the server is advantageous with FM, its 
still very fast to open, you make live changes to the application, and 
they're immediately deployed, even to other active users, and so on. But 
in a low bandwidth scenario filemaker takes a long time to open and is 
slow because its hosted on the server. Putting the data on the server, 
and the application locally is now technically possible with FM7... I 
wonder if anyone has tried it yet to improve low bandwidth performance.)

0
42
6/24/2004 7:01:39 PM
42 wrote:

> (Normally hosting everything on the server is advantageous with FM, its 
> still very fast to open, you make live changes to the application, and 
> they're immediately deployed, even to other active users, and so on. But 
> in a low bandwidth scenario filemaker takes a long time to open and is 
> slow because its hosted on the server. Putting the data on the server, 
> and the application locally is now technically possible with FM7... I 
> wonder if anyone has tried it yet to improve low bandwidth performance.)

Have you tried it with FMP and FMS7?  Quite zippy, even over an internet 
WAN connection.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/24/2004 7:16:27 PM
"42" <42@nospam.com> wrote in message
news:EnwCc.877562$Ig.613315@pd7tw2no...

> Its also worth pointing out that installing and using MSDE is not as end
> user friendly as JET, nor is MSDE the default (in fact its not even
> usually installed.) Nor is there much documentation for MSDE readily
> available... (at least not with Office XP)

That is true, but creating ADP projects are not hard at all. And, the MSDE
install is also quite easy.

Perhaps what is MOST amazing, is that when you use ms-access in this
fashion, you STILL get the drag and drop, and table ER diagramming tools
that you had in ms-access. This means, that you get the SAME ease of use
when it comes to creating tables, and creating relationships etc.ms-access
simply sends the ddl commands to the server. I don't know of ANY other
desktop system that lets you do this. This is AMAZING. You DO NOT need to
know, and learn sql server to create a ADP projects in ms-access. You just
create your tables, and draw lines for your relations, and ms-access somehow
figures this all out for you..and sends the correct commands to sql server
(this is too cool!). There are some who are not too crazy about ADP
projects, and then I know some access developers who swear by them, and will
NOT use any other setup.

>
> And worst of all, JET solutions do not port to MSDE as transparently as
> we could like.

That is true. However, I will say if you develop ADP's from day one, the
development ease of ms-access is there, and you get a sql server application
as a result. This is VERY nice feature.

>
> If we're going to compare FM to Access+MSDE I can live with that, but
> then FM gains a considerable edge when it comes to deployment and an
> even bigger edge in ease of use

Hum, I am not convinced of the above. I never found installing the msde to
be any harder then word, or excel! There is not some big configures issue
here. This server engine even installs on win98, were as sql server needs
win2000 and later. So, the MSDE is able run without using the network domain
logons etc. This makes using the MSDE real easy.

> With
> Access you have to think ahead and target MSDE at the outset... and
> start eating extra admin and deployment headaches right from day one.

I don't think the above is anymore then FileMaker, or most products (I could
be shown wrong on this..but without having deployed the server part of
FileMaker...I can't say much on the comparison..since I have not done both).
There are VB products in the marketplace right now that auto install the
MSDE as part of the install package, and the users never know it.

And, by the way, is there any installing tools and script stuff available
for FM?  Just this week I created some royalty free ms-access installs, and
they are branded with the company logo and name during the install (the
ms-access name never even comes up). The installer even creates a desktop
icon, and shortcut. In addition, I also get the program placed in the
"programs" menu. start->programs. So, to deploy my application, I have a
VERY nice installer, and the icon used for the application, and even things
like the control panels "add-remove" is supported. ( In other words, users
can even un-install my applications). This is so nice, that I actually use
the installer for JUST give clients a file.. I used to have to give my
clients have some instructions, and even explain where things should be
installed. Now, I simply use the standard windows MSI installer. And, I
really find that access package and deployment kit for access 2003 is VERY
nice..the best it has been in years! You don't have to know anything about
making a install, but just answer a few questions to the wizard. As
mentioned, this is so slick, that even when I JUST have to give a simple
database file to a client..I now use this installer. Can your users now go
to the control panel to un-install a application you sent to a client?

So, if you are going to start talking about installing, and setting things
up for a client..I would be most interesting in the kinds of tools that FM
has. I will tell you right now, what I got with a2003 in terms of package
and deployment is a dream. I can bet you right now, my clients have a easer
time to install my stuff, then they do yours!. I save my clients money on
this issue for sure....do you?
>
> Learning SQL is a marketable skill. Learning SQL Server is also
> marketable but the extra specificness doesn't buy you that much,
> especially if you only have practical experience with 'small scale'
> solutions.

Actually, it does get you a lot. sql-server skills are one of the most
marketable skill you can have right now. The last good reports out (year =
2002) showed that Oracle, and most vendors had dropped. Sql-server had in
the same period incused 20%. Companies like Oracle have been in this market
for 20+ years. sql-sever is less then 10? It is REALLY starting to catch on.

> Besides I would think its a poor business strategy to needlessly marry
> my application to Microsoft enterprise servers.

As compared to using a FileMaker solution? I mean, this is really a matter
of choice. Do you have a choice with FileMaker solutions in this regards?
Can you dump the server component here? ms-access certainly seems to cover
the widest swath of possibilities here. We got file share mode, sql server
mode, and also odbc mode? That is really quite amazing to me...

> If I'm going to write
> against client/server SQL backend then I'd prefer to adhere to SQL
> standards as much as possible, to make targeting MySQL, SQL Server,
> Oracle, etc... an option. As a software vendor it makes sense, and as an
> internal system it makes sense.

And, I know of few developers that have succeed in the above. Each vendor
has good many differences, and a good many features (or lack of). If  you
work towards the lowest common sql...your costs go way up. If I am using
ms-access with Oracle, then I have to weight the issue of using oracle
features here. I likely WILL use stored procedures..and that point you are
stuck. We all wish this was not the case..but the "real world" experience
shows otherwise.

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/24/2004 7:23:31 PM
Howard Schlossberg wrote:

> 42 wrote:
> 
>> (Normally hosting everything on the server is advantageous with FM, 
>> its still very fast to open, you make live changes to the application, 
>> and they're immediately deployed, even to other active users, and so 
>> on. But in a low bandwidth scenario filemaker takes a long time to 
>> open and is slow because its hosted on the server. Putting the data on 
>> the server, and the application locally is now technically possible 
>> with FM7... I wonder if anyone has tried it yet to improve low 
>> bandwidth performance.)
> 
> 
> Have you tried it with FMP and FMS7?  Quite zippy, even over an internet 
> WAN connection.

That's what I suspected. Thanks for the confirmation!
0
42
6/24/2004 7:25:56 PM
"Kevin Hayes" <me@here.com> wrote in message
news:cbf5uq$p69$1@zcars0v6.ca.nortel.com...
> David W. Fenton wrote:
>
> > Access can have only one MDB open in the front end. It can connect
> > to any number of back end databases, and can load both forms and
> > data from those back ends (loading forms from a different MDB is a
> > little trickier, of course, but it's how all the Access wizards are
> > implemented).
>
> Really? So if I have multiple unrelated local database solutions (not
> client-server setups), I can only have one open at a given time? If so,
> then that's a pretty bad limitation.

Well, just like word, or excel...you often do, and can launch multiple
copies. So, if you have 3 different access applications, you can run all 3
without problems. This is standard fair. It is just that the current
ms-access session is ONE application, and it can connect to many database
files. If you need to launch, and use another access application..there is
no restricting on this. (so, Excel can have more then one sheet opened..but
ms-access cannot). However, you can run multiple copies of the internet
browser without problems..right? You can also have two copies of Excel
running, and each copy can have more then one sheet opened.

So, you can launch as many ms-access applications as you wish without
problems. And, note that windows DOES share the same copy of ms-access in
memory when you do this, so from a resource point of view..this works just
fine...


-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn



0
Albert
6/24/2004 7:32:45 PM
Albert D. Kallal wrote:

> "Kevin Hayes" <me@here.com> wrote in message
> news:cbf5uq$p69$1@zcars0v6.ca.nortel.com...
> 
>>David W. Fenton wrote:
>>
>>
>>>Access can have only one MDB open in the front end. It can connect
>>>to any number of back end databases, and can load both forms and
>>>data from those back ends (loading forms from a different MDB is a
>>>little trickier, of course, but it's how all the Access wizards are
>>>implemented).
>>
>>Really? So if I have multiple unrelated local database solutions (not
>>client-server setups), I can only have one open at a given time? If so,
>>then that's a pretty bad limitation.
> 
> 
> Well, just like word, or excel...you often do, and can launch multiple
> copies.

[snip]
> So, you can launch as many ms-access applications as you wish without
> problems. And, note that windows DOES share the same copy of ms-access in
> memory when you do this, so from a resource point of view..this works just
> fine...

True enough - I wasn't thinking of the Windows way of opening multiple 
instances of an app. Can I easily commincate between data in different 
MDBs this way?
0
Kevin
6/24/2004 7:46:38 PM
Albert D. Kallal wrote:

<much snippage throughout>

>>If we're going to compare FM to Access+MSDE I can live with that, but
>>then FM gains a considerable edge when it comes to deployment and an
>>even bigger edge in ease of use
> 
> 
> Hum, I am not convinced of the above. I never found installing the msde to
> be any harder then word, or excel! There is not some big configures issue
> here. This server engine even installs on win98, were as sql server needs
> win2000 and later. So, the MSDE is able run without using the network domain
> logons etc. This makes using the MSDE real easy.

Compared to FM (or JET) its a quite a bit more. And in a single user 
evironment it is a little clumsy. I'm not saying MSDE is "hard"... its 
just not the complete non-issue that FM or JET is.

<snips>
> So, if you are going to start talking about installing, and setting things
> up for a client..I would be most interesting in the kinds of tools that FM
> has. I will tell you right now, what I got with a2003 in terms of package
> and deployment is a dream. I can bet you right now, my clients have a easer
> time to install my stuff, then they do yours!. I save my clients money on
> this issue for sure....do you?

This is really probably the most misunderstood aspect of Filemaker, for 
access users.

Installing a single user filemaker solution on a system with FM7 
installed is generally about as difficult as installing a Microsoft 
Office *document*. Installing it on an FM server is about as hard.

If you are using FM developer to put together standalone runtime apps, 
then yes you get your packaged installer to install the database and 
database engine, and what not else.

> 
>>Besides I would think its a poor business strategy to needlessly marry
>>my application to Microsoft enterprise servers.
> 
> 
> As compared to using a FileMaker solution? I mean, this is really a matter
> of choice. Do you have a choice with FileMaker solutions in this regards?

No. I saw that counter argument coming. :) And my only response is that 
FM Servers are dirt cheap vis a vis MS SQL Server, so the marriage isn't 
nearly as costly.

On a SQL backend I tend to prefer to support MySQL and SQL Server. The 
product is a much easier sell that way.
0
42
6/24/2004 7:51:47 PM
On Thu, 24 Jun 2004 06:16:18 -0500, rkc wrote
(in article <6KyCc.114965$j24.5148@twister.nyroc.rr.com>):

[responding to my having stated that in the late seventies I had twenty years 
computing experience]

> What were you working on in 1958,  Great Gramps?

My first computing work  was on the AN/FSQ-7, a vacuum tube computer built by 
IBM especially for use in the SAGE air defense system. Each of the some 
thirty plus SAGE installations included two of these monstrosities. The 
operator's console itself was about five feet high, probably over thirty feet 
wide, and was a sea of blinking lights from floor to ceiling. The computer 
originally came with 64 K words (where a word was 30 bits wide) of memory, 
but this was later increased to, if I remember correctly, 256 K words.  The 
computer consumed enough electricity that each SAGE installation was equipped 
with its own electrical generating plant. Today you would be hard put to find 
any computer at any price with less computing power than the Q-7.

Take a look at

<http://www.mitre.org/about/photo_archives/photos/hi_res/sage_bb11.tif>

for a picture of the Q-7.

-- James L. Ryan -- TaliesinSoft

"My dog never came across a bush he didn't like!"

0
James
6/24/2004 8:16:05 PM
On Thu, 24 Jun 2004 15:16:05 -0500, James L. Ryan wrote
(in article <0001HW.BD00A0B500031F34F03055B0@news.prodigy.net>):

[commenting on the AN/FSQ-7 computer used for the SAGE system]

> The computer originally came with 64 K words (where a word was 30 bits wide) 
> of memory, but this was later increased to, if I remember correctly, 256 K 
> words

Oops, I'm guilty of exaggeration. Correction, the Q-7 originally came with 8 
K 30 bit words which was subsequently expanded to 72 K 30 bit words. 

-- James L. Ryan -- TaliesinSoft

"My dog never came across a bush he didn't like!"

0
James
6/24/2004 8:38:46 PM
RE/
>(Normally hosting everything on the server is advantageous with FM, its 
>still very fast to open, you make live changes to the application, and 
>they're immediately deployed, even to other active users, and so on.

To me, the two big reasons to separate app/data are:

1) Maintainability.   I can work on a copy of the app and then elevate it to
production status without interrupting the user's workflow.

2) Reliability.  Who knows what some of those power users are going to do to my
precious app?   Accordingly, I keep a master version in a read-only directory on
the LAN and download a copy to each user's C:\Temp when they run it.
-- 
PeteCresswell
0
Pete
6/24/2004 9:49:30 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfvr9u.11gy5z81p11ibkN%lynn@NOT-semiotics.com: 

> NB <nickbose@softhome.net> wrote:
> 
>> Hmm,  why don't they provide SQL functionality? That's a point I
>> missed in the original post.
>> I thought version 7 would have tackled that.
>> 
>> FM camp: Now forget about VBA, is it possible to implement in FM
>> a stack (nested) query, says 3 or 4 levels (that means the
>> retrieval criteria is so complex that you need to write an SQL,
>> then another SQL to extract data from the first one, then a third
>> SQL to get the data from the second one, and so on ....) ?
> 
> FM (versions 5 & up) does indeed provide SQL functionality. Any
> SQL query you can write can be built in FM, and there's no reason
> you couldn't write a nested query, if you know how.

You mean, I can paste this into FM:

SELECT Field1, Field2, Field3
FROM MyTable
WHERE Field1>0
ORDER BY Field3, Field2 DESC 

and it will return data?

Or are you saying that through entirely different methods you can
retrieve the same data? 

> I've only done very simple SQL queries in FM to pull data out of
> (MS-SQL) tables, and haven't ever needed to push data back, but
> that's also possible.  I'd say one's ability to write such queries
> would be limited by one's SQL skills, rather than by FM.  One
> writes the query into a global text field (usually with a script,
> using parameters entered in fields) and then implements the Send
> SQL script step to execute it.

Yet, Access provides a full SQL editor that allows you to write SQL
without needing to know SQL. 

Surely that's more flexibility than you describe FM as providing.

And it also sounds like you are only passing through SQL to the
back-end database engine, and FM itself doesn't do SQL with its own
database engine. 

Access allows you to write pass-through queries that are handed off
to the server for processing. But it allows you to use SQL against
every single data source you have available to you. In other words,
you have one method for your data retrieval (obviously, with
variations depending on the back end's SQL dialect), one that is
universal in the world of databases. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:01:52 PM
(Pete Cresswell) wrote:

> RE/
> 
>>(Normally hosting everything on the server is advantageous with FM, its 
>>still very fast to open, you make live changes to the application, and 
>>they're immediately deployed, even to other active users, and so on.
> 
> 
> To me, the two big reasons to separate app/data are:

You missed my point. Just because everything is on the server doesn't 
mean they have to be in the same file. FM7 fully supports separating 
code from data into separate files, *and* having both those files on the 
server.

> 1) Maintainability.   I can work on a copy of the app and then elevate it to
> production status without interrupting the user's workflow.

FM allows this too.

> 2) Reliability.  Who knows what some of those power users are going to do to my
> precious app?   Accordingly, I keep a master version in a read-only directory on
> the LAN and download a copy to each user's C:\Temp when they run it.

FM Allows this too. But you don't have to download the copy to each 
users C:\temp to deploy it. You can just swap the file on the server.

0
42
6/24/2004 10:03:51 PM
Kevin Hayes <me@here.com> wrote in
news:cbf5fi$ok1$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Kevin Hayes <me@here.com> wrote in
>> news:cbej81$3gp$1@zcars0v6.ca.nortel.com: 
>> 
>> I guess I didn't make it clear: the part that suprised me was not
>> that she made the original design error (lots of people make that
>> error), but that it was so frigging complicated to copy the
>> results of string functions into the new fields. And that the
>> methods suggested by other FM users didn't seem to work for her. 
> 
> It is very easy to do what you described. It is not FMs fault her
> and her coworkers are ignorant of the product. A simple script
> would do it. Or, as you said, an SQL statement.

Well, none of the people who were users of FM could figure out how
to do it. 

That doesn't sound terribly easy or intuitive.

And would SQL run against a FM database?

What exactly is the role of SQL in FM?

>>>>In today's world, if it doesn't support SQL, I'm sorry, but it's
>>>>not really a serious database product. 
>>>
>>>Firstly, the "I'm sorry" is a bit condescending, don't you think?
>> 
>> 
>> Fully intended. SQL is the lingua franca of all databases,
>> worldwide. Not supporting it makes the product far, far less easy
>> to use for people who already have database experience. 
> 
> I think you are missing the point of the product. It's a product
> to make databases for end-users with little dbms experience. It
> does its job very well, thank you.

Well, I wouldn't disagree with that characterization based on what I
know about FM. 

But what I've been hearing is that FM is just as powerful as Access
for developing database applications. It doesn't sound that way to
me. 

>> Maybe FM is really easy for people who know nothing about
>> databases, and that's a really good thing, but if people who *do*
>> know databases have to learn everything from scratch to use it
>> (because it doesn't support industry standards), then it is less
>> suitable as a database development platform for anyone but the
>> novice. 
> 
> No, it simply means developers have to drop the arrogance and
> realize it's a different tool. Learning new ways of doing things
> is a good way. If FM worked like every other DB tool, then what is
> the point of using it? 

If it supported SQL for all data retrieval (though not requiring the
end user to write it) it would mean that everyone with db experience
would have an easy time picking it up. This would make it more
attractive for people who already work with databases. 

Like me, for instance.

>> A database product that doesn't support SQL is like a web browser
>> that doesn't support HTML. 
> 
> That is BS. It is more like saying a book is no good because the
> author didn't use Microsoft Word to write it. The purpose of a web
> browser is to display HTML. The purpose of a databsae system is to
> develop solutions to hand users' data. FM does this very well. The
> underlying technology is irrelevant. Moot point anyway, as FM does
> have SQL. 

I don't think you understand the role of SQL in the database world.
Joe Celko writes all these books about doing cool and complex and
elaborate things in SQL, and with few exceptions, all of it is
applicable to any database that supports SQL. 

That's the meaning of the term "lingua franca."

And it's not clear to me whether FM speaks it or not. It appears
from what others have said that it can handle SQL that is just
handed off to a server database for processing (what's called a
pass-through query in Access), but it's not clear to me that FM
itself speaks SQL. 

>> And with SQL, the problem this poor woman had with copying data
>> to a new field would have been trivial. There would have been
>> dozens of people who've never used FM who could have given her
>> the SQL to copy the data. 
> 
> FM does have SQL. Either her or her coworkers didn't know that. As
> I stated in a previous post in this thread, FM often gets blamed
> because people don't know the capabilities of the product.

Why would those who promote FM downplay its support of SQL?

I don't see anything about it on the Filemaker website in regards to
SQL Server 7. I do see that there is an ODBC driver provided, and
you could then use SQL from another application to manipulate data
in Filemaker. 

But can you, within the Filemaker UI, use SQL to retrieve data for
populating forms and listboxes and reports and the like? 

It doesn't look that way to me. I used Google to search
Filemaker.com, using these keywords for the search: 

 SQL site:filemaker.com -"sql server" "filemaker 7"

There's nothing there that says anything about SQL being usable
within FM itself. Indeed, from this reprint of an article that
appeared in USA Today: 

http://www.filemaker.com/customers/stories/671.html

there is this quote:

    "Integration with our other systems was one issue," Miles
    comments, "especially SQL integration. Getting IT approval was
    another concern." 

    But every problem has a solution. "We bought a SQL plug-in,"
    says Miles, and the result was very functional."  

That doesn't sound like SQL is part of FM. Then again, it's not
clear when that article was published nor which version of FM it was
referring to. 

Help me out here, folks. Does FM offer SQL in Filemaker, or only
from an outside product accessing Filemaker data via ODBC? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:21:05 PM
"K&V P" <random_characters@shaw.ca.invalid> wrote in
news:2PECc.885672$Ig.402677@pd7tw2no: 

> "David W. Fenton" wrote...
>> "K&V P" wrote:
>>
>> > "David W. Fenton"  wrote...
>> >> 4GBs in a single field? Why would anyone need that?
>> > "640k should be enough for anybody."
>> >                   - - Bill Gates, 1981
>> > Maybe you're too young to remember where that one got us?
>> I didn't say no one would need it. I asked why.
>> Please explain how one would use a 4GB field.
> 
> And neither did I, say that anyone would have a use for it
> (today). 
> 
> What I intentionally implied is that it is short-sighted to
> criticize something for being capable of more than is needed
> today. 

Read my lips please: I'm asking for potential uses, not criticizing
it as useless. Maybe I can't think of a use for it, but someone else
could. 

It certainly isn't an advantage that I could see being worth putting
on a checklist. 

> If I compile a solution that permits storage of video files
> internally (for security), and ten years from now someone decides
> they want to use that solution to store a variety of 6 hour
> instructional videos on an optical storage Welton Cube that holds
> 4 terabytes of data, maybe they can. Maybe they won't have to go 
> looking for someone to update it to newer technology, Which, no
> matter how many new bells and whistles it has, there-by renders
> their existing body of data useless.

Well, my experience tells me that it's never a good idea to store
BLOB data in a proprietary database format. Instead, it's better to
store in the file system, where you have security and backup at a
completely different level. 

> 7 years ago, I spent nearly 20 hours extracting data from a DOS
> database for a local church because they needed to switch away
> from the custom solution they were using due to space limitations
> imposed by Mr. Gates. 
> 
> There are enough limitations around us to make it absurd to imply
> criticism of something for having an unusually large limitation on
> something. 
> 
> That's without even getting into the philosophical fallacy of
> turning an un-required positive into a negative in an argument.

What use is there for a 4GB field size?

You've provided one justification for storing BLOBs in a data field,
security. 

Color me unimpressed.

The only scenario where I ever felt it was useful in Access was with
replicated databases, where you could store a document in a data
field and it would be synchronized with the other replicas in the
replica set. 

Does FM support replication?

If not, I just can't see a use for it.

That doesn't mean there isn't one, just that no one has offered one
that seems that it provides features that are really helpful. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:24:44 PM
Kevin Hayes <me@here.com> wrote in
news:cbf5mu$otl$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Please explain how one would use a 4GB field.
> 
> To store binary data.
> - archives of image sets or other large files
> - boot disk images for lab computers
> - video footage

Why would you store any of this data in a field of a record in a
data table and not in the file system, with a pointer to that stored
in the database? 

The point is not that there isn't data of that size, since there
quite obviously is. The point is justifying why you'd store it in
the data table. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:25:50 PM
The worst thing - and it is still the same in FM7 - is the scriptmaker.
This is really a child's toy.and un-professional.



"Kevin Hayes" <me@here.com> wrote in message
news:cbcias$7di$1@zcars0v6.ca.nortel.com...
> Saintor wrote:
> > I disagree.  I gave it a try hoping for something better than Access.  I
> > tried FM and also Alpha Software.  In both cases, I gave up.  Went back
with
> > Access, which is much better IMO.  FM is not particularly cheap either.
> > There is only one feature that I miss in Access.   FM flies (I had the
> > network version); speed of processing data is very good.
>
> What couldn't FM do that you wanted?


0
Saintor
6/24/2004 10:32:09 PM
42 <42@nospam.com> wrote in news:jqFCc.876528$oR5.410053@pd7tw3no:

> David W. Fenton wrote:
> 
>> 42 <42@nospam.com> wrote in news:EnwCc.877562$Ig.613315@pd7tw2no:
>> 
>>>If we're going to compare FM to Access+MSDE I can live with that,
>>>but then FM gains a considerable edge when it comes to deployment
>>>and an even bigger edge in ease of use, not to mention that there
>>>is no migration required to scale a single user to a multiuser
>>>version. With Access you have to think ahead and target MSDE at
>>>the outset... and start eating extra admin and deployment
>>>headaches right from day one. 
>> 
>> Sorry, but everyone is avoiding answering the original question:
>> 
>> Where does FM perform better as compared to Access?
> 
> As in you want a specific query against a specific database in a 
> particular network configuration?
> 
> If you can find a series of recent benchmarks I'd *love* to see
> them. 

You mean you don't have any and you're part of the crew claiming FM
is faster? 

>> In what scenarios?
> 
> Faster development, easier to use, easier to deploy. Those are
> gimmes. . . 

No, those are not performance-related.

And I don't see any evidence offered by anyone as to how FM is
faster than Access in any of those areas. Any citations for that at
all? 

> . . . Actual performance of a given query or sort or something,
> I can't say which is faster when, both are quite good, and they
> can both be coded badly enough to be brutally slow.

But the claim is that FM outperforms Access. I want to know why
people say that. 

> Filemaker also scales up much higher than Access in the number of 
> simultaneous users while retaining its speed, unless you put a SQL
> Server backend in... but then that's not really access anymore.

Excuse me?

It's not Access for the data storage, but it's still Access for the
design of the whole front end, you know, the part the end user
interacts with. 

If your application outgrows the capabilities of the Jet database
engine, you have your choices of back end. Indeed, Access since A2K
has shipped with a server back end. 

Of course, it's rather hard to exceed what Access/Jet can do, unless
you've got a large number of users (over 50) and/or high concurrency
issues. 

FM provides a seamless migration to the server, or at least I assume
it's as easy as moving to the server version, right? 

Of course, if you're going to compare a FM database that started out
using the server-based back end, then it's really quite unfair to
compare that to an Access application that's using Jet from the
beginning. 

Access against MSDE would probably perform just as well were it not
for MS's decision to throttle it at 5 simultaneous connections. 

So, you'd probably have to go to SQL Server, yes.

But you also have the choice of using something free, like
PostgreSQL or MySQL. 

And you don't have to discard your front end design (though you may
need to re-architect it). 

>> In what kind of operations?
>> 
>> Ease of deployment is simply not relevant to that question.
> 
> Ah, and here I thought someone asked where the two products
> various strengths lie.

How often do you deploy?

Not nearly as often as you retrieve data.

I don't mean to say it's not helpful for deployment to be easy, but
I just don't see deployment of Access applications as difficult. 

What, exactly, is difficult about it?

>> The allegation was that FM is faster than Access for retrieving
>> data. I want some factual information to support that allegation.
> 
> Maybe I missed it, but I haven't seen anyone actually allege that.
> There are no reliable benchmarks. And everybody knows you can make
> either database win a benchmark by designing the other one badly
> enough. 

Performance has been cited several times, by several different FM
advocates. I have asked for proof each time. 

There is none, obviously.

And it's pretty clear by your "if it's a SQL Server back end, it's
not Access any more" that you really don't have a clue about what
you're talking about. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:32:44 PM
"K&V P" <random_characters@shaw.ca.invalid> wrote:

>7 years ago, I spent nearly 20 hours extracting data from a DOS database for a
>local church because they needed to switch away from the custom solution they
>were using due to space limitations imposed by Mr. Gates.

Umm, IBM were responsible for the 640kb limitation as that is hardware.

Tony
--
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
http://www.granite.ab.ca/accsmstr.htm
0
Tony
6/24/2004 10:33:50 PM
Kevin Hayes <me@here.com> wrote in
news:cbf5uq$p69$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Access can have only one MDB open in the front end. It can
>> connect to any number of back end databases, and can load both
>> forms and data from those back ends (loading forms from a
>> different MDB is a little trickier, of course, but it's how all
>> the Access wizards are implemented). 
> 
> Really? So if I have multiple unrelated local database solutions
> (not client-server setups), I can only have one open at a given
> time? If so, then that's a pretty bad limitation.

You can certainly have multiple instances of Access open at one
time. 

But I thought you were asking about multiple databases open in one
instance of Access. Only one of them can be the current database in
the UI, but you can get to data in any number of back ends (whether
MDBs or SQL Servers or Excel files or comma-delimited text files and
so forth), and you can utilize UI objects from other MDBs in the
front end. 

I'm failing to see where there's any advantage for FM on this point,
unless I'm completely misunderstanding the point being made. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:34:32 PM
Kevin Hayes <me@here.com> wrote in
news:cbfaua$1ln$1@zcars0v6.ca.nortel.com: 

> Albert D. Kallal wrote:
> 
>> "Kevin Hayes" <me@here.com> wrote in message
>> news:cbf5uq$p69$1@zcars0v6.ca.nortel.com...
>> 
>>>David W. Fenton wrote:
>>>
>>>>Access can have only one MDB open in the front end. It can
>>>>connect to any number of back end databases, and can load both
>>>>forms and data from those back ends (loading forms from a
>>>>different MDB is a little trickier, of course, but it's how all
>>>>the Access wizards are implemented).
>>>
>>>Really? So if I have multiple unrelated local database solutions
>>>(not client-server setups), I can only have one open at a given
>>>time? If so, then that's a pretty bad limitation.
>> 
>> Well, just like word, or excel...you often do, and can launch
>> multiple copies.
> 
> [snip]
>> So, you can launch as many ms-access applications as you wish
>> without problems. And, note that windows DOES share the same copy
>> of ms-access in memory when you do this, so from a resource point
>> of view..this works just fine...
> 
> True enough - I wasn't thinking of the Windows way of opening
> multiple instances of an app. Can I easily commincate between data
> in different MDBs this way?

Of course you can.

That's why I can't understand the issue you're raising. Your
question is so profoundly ignorant of how Access works that I didn't
even recognize the subject. 

In one instance of Access, the open MDB file can provide access to
data (full read/write access, if that's been granted) to any MDB in
the file system available to the session of Access. You can also run
forms and reports from library databases not open in the Access UI. 

I don't see from what anyone has said here that FM offers anything
more than this. 

Indeed, it's not clear to me if it offers as much.

Can FM use library databases, i.e., a FM database with shared
objects that can be used by other database applications
transparently? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:37:43 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dm7mo87qafi87@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Let's talk about some scenarios. Let's try out some things. I've
>> got the demo so I can try things out and see how they compare on
>> my system (though I don't have a server to do client/server
>> testing). 
> 
> I wish I could be more specific, but I don't have the current
> version of Access to test against.  Some areas where I would
> invite a comparison: 
> 
> 1) search on multiple criteria over a million records (either
> scripted or query by example;

Are we talking about properly indexed fields?

Are we talking about using Jet for the back end or a file server
database? 

> 2) sort a million records on multiple fields;

Are the fields indexed?

> 3) access a database over a WAN, with nothing on the client except
> for the app itself (i.e. no MDB or FP7 files);

What bandwidth WAN?

What kind of back end?

Certainly with Jet it likely won't work well.

But if you're comparing it to the server-side version of the FM
database engine, then you've already rigged the comparison in FM's
favor. 

And, of course, if you don't want to re-engineer your application
and migrate it the back end to SQL Server, you can run it on the
server with Windows Terminal Server, which is quite usable even over
a 28.8 dialup. 

You could, of course, do the same thing with FM for Windows.

> These tasks (searching and sorting) would seem to be the most used
> features, and the easiest to strip the apps to their bare bones
> (without relying on the efficiency of different scripting
> techniques).  And these are features where I feel FM7 is strong.

I doubt there will be any great difference between FM and Access in
these, unless you give FM an advantage by using the server-side
version of it. In that case, the proper comparison would be to
Access with MSDE/SQL Server. 

> Any other ideas from an Access perspective?

I really don't think it's likely there will be any differences.
Querying and sorting a million records is trivial, unless you're
talking about doing it on unindexed fields. In that case, given a
server-side database engine, I don't think there will be significant
differences there, either. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:42:41 PM
42 <42@nospam.com> wrote in news:nyFCc.876557$oR5.555873@pd7tw3no:

> David W. Fenton wrote:
> 
>> 42 <42@nospam.com> wrote in
>> news:MYqCc.864558$oR5.825340@pd7tw3no: 

>>>You can put the database tables in one or more files, and put the
>>>front end layouts and scripts in one or more different files. You
>>>can have multiple front ends accessing the same files.
>> 
>> Yes, that's exactly what you can do in Access.
> 
>> Can FileMaker do the same?
> 
> Actually I *was* talking about FM.

And my point should be clear: all the things you've said are FM
advantages are also available (and pretty standard stuff) in Access. 

>>>>... and in what way might it be "better"?
>>>
>>>It might be better if it provided more tools to assist the
>>>user/develop in maintaining that boundary.
>> 
>> What boundary?
> 
> The boundary between application and data.

Er, every single one of my Access applications maintains a strict
boundary between application and data. 

[]

>> The standard configuration for an Access multi-user application
>> is an MDB file with the forms, reports and so forth on the client
>> workstation and a shared MDB for data on the file server if
>> you're using Jet to store the data, and if not, then a server
>> database of your choice to store the data. 
> 
> The standard solution for FM multiuser apps is to host everything
> on the server. Until v7 the access way you describe wasn't really
> an option. I wonder how well it would work in v7?
> 
> (Normally hosting everything on the server is advantageous with
> FM, its still very fast to open, you make live changes to the
> application, and they're immediately deployed, even to other
> active users, and so on. But in a low bandwidth scenario filemaker
> takes a long time to open and is slow because its hosted on the
> server. Putting the data on the server, and the application
> locally is now technically possible with FM7... I wonder if anyone
> has tried it yet to improve low bandwidth performance.) 

That's the standard approach for Access as it lowers contention
among users for the application file. 

I think it's pretty clear here that people are claiming for FM as
exclusive capabibilities features that Access has offered for more
than ten years. 

I'm not really wanting to be combative here, because I'm interested
in FM. 

But please, let's keep the discussion on the level that reflects
actual kowledge of the competition. I've not tried to say anything
about what FM can and can't do except if I've researched it. 

Please give us Access users the same courtesy in this discussion.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:46:50 PM
"Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in
news:TSFCc.885939$Ig.588156@pd7tw2no: 

> I will say if you develop ADP's from day one, the
> development ease of ms-access is there, and you get a sql server
> application as a result. This is VERY nice feature.

You could also use an ADP for nothing but creating and managing your
MSDE/SQL Server database and build your application in an MDB that
connects to it. In that respect, you get the ease of use of doing it
all in an MDB with the small annoyance of dipping into the ADP to
alter the database. Of course, in any properly engineered Access/Jet
app you'd be doing the same thing, with a separate data MDB. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 10:49:30 PM
NB <nickbose@softhome.net> wrote:

> Please give some comments too, particularly
> in comparison to the more popular Access and FM.

as Kevin said :

- need very complicated things with a real programming tool, C++ plugins
etc... : 4D is the powerful but user-friendly tool. 4D is more to
compare to Oracle (windows version) than to access.
- need powerful but not too sophisticated things : FMP

access is between the 2, but not so easy to use. No place for it.
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/24/2004 10:59:04 PM
Albert D. Kallal <PleaseNOOOsPAMMkallal@msn.com> wrote:

> where as the real problem is
> that scripting language is TOO complex for a lot of admins).

it's the truth. So, they have better using FMP... with a better result,
in time and quality.

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/24/2004 10:59:05 PM
Kevin Hayes <me@here.com> wrote:

> I really don't see 
> the point of using Access unless people already have it on their PCs.

it's the same with Word...

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/24/2004 10:59:05 PM
42 <42@nospam.com> wrote in news:bdICc.842057$Pk3.108771@pd7tw1no:

> (Pete Cresswell) wrote:
> 
>> RE/
>> 
>>>(Normally hosting everything on the server is advantageous with
>>>FM, its still very fast to open, you make live changes to the
>>>application, and they're immediately deployed, even to other
>>>active users, and so on. 
>> 
>> To me, the two big reasons to separate app/data are:
> 
> You missed my point. Just because everything is on the server
> doesn't mean they have to be in the same file. FM7 fully supports
> separating code from data into separate files, *and* having both
> those files on the server.

Er, well, Access works exactly the same way.

Think about it logically.

It's pretty clear from Access's ability to connect to any number of
data sources that the program logic and the data storage are
separable. 

>> 1) Maintainability.   I can work on a copy of the app and then
>> elevate it to production status without interrupting the user's
>> workflow. 
> 
> FM allows this too.

Well, Access always has done so, which is why there is confusion
over the claim that this is some kind of special feature of FM. It's
so basic to Access that it was hard to understand what was being
alleged. 

>> 2) Reliability.  Who knows what some of those power users are
>> going to do to my precious app?   Accordingly, I keep a master
>> version in a read-only directory on the LAN and download a copy
>> to each user's C:\Temp when they run it. 
> 
> FM Allows this too. But you don't have to download the copy to
> each users C:\temp to deploy it. You can just swap the file on the
> server. 

Well, Access allows that, too, but it's not a recommended
configuraiton. 

The problems of deploying updates to the client workstation are
pretty minor. 

It's interesting if FM has managed to make sharing the front end
file safe and reliable. 

I still wouldn't do it, though, as I'd always want the development
and depolyed copies to be different. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/24/2004 11:03:24 PM
NB wrote:
>>VB. But then again, 4D has an extensive language too. I would sooner use 
>>4D than Access if I wanted a programming-based database. And 4D is cross 
>>platform too. I really don't see the draw to Access, other than people 
> 
> 
> I heard of 4thD before but never had time to take a long look.
> Has anyone here tried it? Please give some comments too, particularly
> in comparison to the more popular Access and FM.
> 
> Thks
> 
> NB


4D is definately worth a look; had FM7 been much longer to release, I 
would have migrated. FM7 now offers a number of things 4D has had for yonks.
  Free for academia too


Chris Brown
Neurosurgery
University of Adelaide

0
Chris
6/24/2004 11:19:07 PM
David W. Fenton wrote:

> I don't know what you should choose. Obviously Access is not and
> never will be cross-platform. That's one of the things I don't like

Microsoft would loose OS ground to Linux/Mac even faster than it is now, 
especially in the SMB market.

> about it. I think part of the reason for it is that the multi-user
> capabilities of Access are intimately connected to the way the
> Windows file systems work (I would, for instance, never recommend
> storing MDBs on a SAMBA or NETWARE server).
> 

SAMBA is working quite well for us. The main mdb file is stored in a Linux 
server and accessed via windows workstations. Performance is quite good.

BTW, I agree that SQL is an integral element for serious db development.

> The fact that FM is cross-platform is the only reason I've
> downloaded it to evaluate.
> 



-- 
Thanks a million!
0
aW
6/24/2004 11:38:31 PM
pmanet@invivo.edu (manet) wrote in news:20040625005905986693@[10.0.0.1]:

> Albert D. Kallal <PleaseNOOOsPAMMkallal@msn.com> wrote:
> 
>> where as the real problem is
>> that scripting language is TOO complex for a lot of admins).
> 
> it's the truth. So, they have better using FMP... with a better result,
> in time and quality.

Are you saying that FM is for the incapable?

-- 
Lyle
(for e-mail refer to http://ffdba.com/)
0
Lyle
6/25/2004 12:02:18 AM
aW <a@no.spam.net> wrote in news:40db650e_5@127.0.0.1:

> David W. Fenton wrote:

>> about it. I think part of the reason for it is that the
>> multi-user capabilities of Access are intimately connected to the
>> way the Windows file systems work (I would, for instance, never
>> recommend storing MDBs on a SAMBA or NETWARE server).
> 
> SAMBA is working quite well for us. The main mdb file is stored in
> a Linux server and accessed via windows workstations. Performance
> is quite good. 

It may be, but I wouldn't recommend it. If there's nothing but
non-Windows servers in an operation I question why they'd be
developing in Access in the first place. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
dXXXfenton (2542)
6/25/2004 12:18:19 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> You mean, I can paste this into FM:
> 
> SELECT Field1, Field2, Field3
> FROM MyTable
> WHERE Field1>0
> ORDER BY Field3, Field2 DESC 
> 
> and it will return data?

Yes.

That is, I wouldn't use Paste, I'd use Set Field and build the SELECT
statement using calculation functions. I'd probably store my parameters
in fields so they could be dynamically changed without having to
re-program the entire thing.  Then a script command transmits the whole
thing to the SQL database using an ODBC driver.

The return of data is typically much faster than even a native FM find.
Don't blink.
 
> 
> > I've only done very simple SQL queries in FM to pull data out of
> > (MS-SQL) tables, and haven't ever needed to push data back, but
> > that's also possible.  I'd say one's ability to write such queries
> > would be limited by one's SQL skills, rather than by FM.  One
> > writes the query into a global text field (usually with a script,
> > using parameters entered in fields) and then implements the Send
> > SQL script step to execute it.
> 
> Yet, Access provides a full SQL editor that allows you to write SQL
> without needing to know SQL. 
> 
> Surely that's more flexibility than you describe FM as providing.

Well, let's not pretend that writing simple queries is really that hard.
I had far more trouble getting the darn syntax right for identifying the
table properly in the statement than getting the WHERE to work.  (don't
ask me why "MyTable" didn't work, it HAD to be "MyDatabase_MyTable")  

There are FM tools that will write your SQL for you, at reasonable cost.
It's not part of the basic app because very few people, at this point,
require it.
 
> And it also sounds like you are only passing through SQL to the
> back-end database engine, and FM itself doesn't do SQL with its own
> database engine.

Um no. Nobody ever said it did. The FM database engine is proprietary.
One can pull & push data out of and into SQL tables, which means FM can
act as either a front end to a SQL system, or just share data among
different systems within an enterprise. Perhaps not surprisingly,
sometimes companies want small discrete systems built in FM, NOT SQL,
because it's easier, cheaper and more flexible to develop and maintain.

Also, sometimes there are things we can do in FM that the SQL folks
simply don't want to approach. We've got an enterprise system in place
that interacts with Timberline accounting, which is based in Pervasive
SQL. When we told the Timberline support/engineers what the (complex and
idiosyncratic) structure of the company's bonus and commissions reports
is, they just said "we can't do that."  So we did it in FM.  
> 
> Access allows you to write pass-through queries that are handed off
> to the server for processing. But it allows you to use SQL against
> every single data source you have available to you. In other words,
> you have one method for your data retrieval (obviously, with
> variations depending on the back end's SQL dialect), one that is
> universal in the world of databases.

Really? Even those that don't support SQL? Like, say, Quickbooks? FM can
connect directly to it, using a plugin.  While FM has many methods of
data retrieval, I see that as a feature, not a weakness.  One size does
not fit all, and one method of data retrieval will certainly fail at
some point. The entire world is not SQL, nor is it Windows.

If you want to really blow your preconceptions all to hell, go to
www.servoy.com.   It's what I use when SQL is the preferred data storage
tool, and when I want a nice FM-like front end, crossplatform, with
massive capacity.

FM isn't always the correct tool, but often it is.

Lynn Allen
www.semiotics.com


FM 7 Tip of the Week: Field Behavior allows developers to choose entry
options like permitting entry into a field in Find mode but not Browse,
and whether a field is exited by Tab, Enter or Return keys (or all
three). No more scripts to "protect" fields!  
  
0
lynn
6/25/2004 1:00:26 AM
> I think you are missing the point of the product. It's a product to make 
> databases for end-users with little dbms experience. It does its job 
> very well, thank you.

Does it mean: FM is for non-programmer users to create their own "application" ?

> technology is irrelevant. Moot point anyway, as FM does have SQL.
> FM does have SQL. Either her or her coworkers didn't know that. As I 
> stated in a previous post in this thread, FM often gets blamed because 
> people don't know the capabilities of the product.

I am really confused here. Can someone clarify: does FM do SQL?

NB
0
nickbose
6/25/2004 1:03:13 AM
"42" <42@nospam.com> wrote in message
news:nhGCc.876732$oR5.648526@pd7tw3no...

> <snips>
> > So, if you are going to start talking about installing, and setting
things
> > up for a client..I would be most interesting in the kinds of tools that
FM
> > has. I will tell you right now, what I got with a2003 in terms of
package
> > and deployment is a dream. I can bet you right now, my clients have a
easer
> > time to install my stuff, then they do yours!. I save my clients money
on
> > this issue for sure....do you?
>
> This is really probably the most misunderstood aspect of Filemaker, for
> access users.
>
> Installing a single user filemaker solution on a system with FM7
> installed is generally about as difficult as installing a Microsoft
> Office *document*. Installing it on an FM server is about as hard.
>
> If you are using FM developer to put together standalone runtime apps,
> then yes you get your packaged installer to install the database and
> database engine, and what not else.

Yes, and so is ms-access that way. However, OFTEN you are MUCH better off to
setup where and what folder the document will go into:
My actual point here is that most of the time, you simply "copy" the
application to each pc, and place it anywhere you want. However, the install
tools are soo nice, that instead of telling you hey, here is this file, put
it in my documents, I am using the installer to eliminate this SIMPLE task.

My point is that the installer is SOO easy, that I now even use it in place
of what would be a simple file copy. The reasons are:

    It creates a directory for the target file in one of standard folders
(my documents, my applications, my desktop etc).

    It makes a entry in the add/remove program in the control panel (so now
users can remove the file) More important tech support can remove the
application also

    It means support staff etc can assume, and know what directory the file
is in.

Are you telling me that you actually use the FM installer in place of simple
file copy? (that was/is my point here!). In other words, I not even talking
about installing the runtime system, but simply using that installer in
place of what would be a simple file copy. I don't want to have to write up
bunch of instructions as to where to place a simple stupid file. Again, what
was issue here is how do you mange and deploy software to each pc. The
question was in regards to support, and deployment. If people as a general
rule use the FM installer in place of what is a simple file copy, then I am
surprised

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/25/2004 1:04:27 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> Of course, it's rather hard to exceed what Access/Jet can do, unless
> you've got a large number of users (over 50) and/or high concurrency
> issues.

FM Server allows up to 250 concurrent LAN users. A seat must be licensed
for each client, but otherwise no additional costs. Larger installations
split files and share the load over several servers. 

There are no "concurrency issues" with FM. It seamlessly handles record
locking between clients. This has always been a feature of FM
networking, there is no programming whatsoever required to ensure
editing integrity. 
> 
> FM provides a seamless migration to the server, or at least I assume
> it's as easy as moving to the server version, right?

Yes, generally, if one has paid attention to proper solution design. I'm
assuming Access has some of the same issues, but perhaps not. There are
particular behaviors of certain elements in FM which could trip an
inexperienced developer in moving from peer-to-peer shared files to a
network-hosted version. 

But given proper design from the outset there should be zero need to
rebuild or reprogram files for server hosting.

Lynn Allen
www.semiotics.com

  
 
0
lynn
6/25/2004 1:09:06 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> Can FM use library databases, i.e., a FM database with shared
> objects that can be used by other database applications
> transparently?

No. FM objects are not separable from the files themselves. I'd say this
is the biggest drawback of FM, the intermingling of data and code. :/

We hates it, we do. But on the other hand, I suspect a great deal of the
"ease of use" comes from this structure.

Lynn Allen
www.semiotics.com
0
lynn
6/25/2004 1:24:55 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> I don't see anything about it on the Filemaker website in regards to
> SQL Server 7. I do see that there is an ODBC driver provided, and
> you could then use SQL from another application to manipulate data
> in Filemaker. 
> 
> But can you, within the Filemaker UI, use SQL to retrieve data for
> populating forms and listboxes and reports and the like? 
> 
> It doesn't look that way to me. I used Google to search
> Filemaker.com, using these keywords for the search: 
> 
>  SQL site:filemaker.com -"sql server" "filemaker 7"

Well, the shoe's on the other foot here. You're clearly not even
marginally familiar with FM.  FM objects are similar but not identical
to other database ojbects.  It's a consequence of the integration of
data and coding which plagues all advanced FM users.

SQL data, once retrieved from SQL sources in the FM files, can be
manipulated the same as any other data, of course. It can appear in
"found sets" (=queries) and on layouts (=forms), in value lists
(=listboxes) and in reports (=query +form) which are basically layouts
structured to present the data as required by the user.

One does not use SQL statements WITHIN FM. In fact, FM cannot act as an
ODBC datasource for itself.  In practical tests, FM is a piss-poor
datasource for an ODBC connection when the returned dataset is more than
a few records. FM itself will not tell you this, but while a SQL query
from FM to pull records in can be blazing fast, any ODBC connection
coming in is going to crawl.

FM is much better at user interface and building business rules into
software than it is as a raw dataholder and number cruncher.  It's not
the tool to be digging into with SQL. It's the go-between for
innumerable other data systems in an enterprise, rather than the
preferred data repository for huge data loads.

Lynn Allen
www.semiotics.com

  
0
lynn
6/25/2004 1:24:55 AM
"Lynn allen" <lynn@NOT-semiotics.com> wrote in message
news:1gfwcuj.2620kz1ju9hwvN%lynn@NOT-semiotics.com...
> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>
> > Of course, it's rather hard to exceed what Access/Jet can do, unless
> > you've got a large number of users (over 50) and/or high concurrency
> > issues.
>
> FM Server allows up to 250 concurrent LAN users. A seat must be licensed
> for each client, but otherwise no additional costs. Larger installations
> split files and share the load over several servers.
>
> There are no "concurrency issues" with FM. It seamlessly handles record
> locking between clients. This has always been a feature of FM
> networking, there is no programming whatsoever required to ensure
> editing integrity.
> >
> > FM provides a seamless migration to the server, or at least I assume
> > it's as easy as moving to the server version, right?
>
> Yes, generally, if one has paid attention to proper solution design. I'm
> assuming Access has some of the same issues, but perhaps not. There are
> particular behaviors of certain elements in FM which could trip an
> inexperienced developer in moving from peer-to-peer shared files to a
> network-hosted version.
>
> But given proper design from the outset there should be zero need to
> rebuild or reprogram files for server hosting.
>



Lynn,

Access allows 255 concurrent users - no extra licence per seat required -
for a Jet (fileserver) backend, or the limit imposed by the RDBMS if using
other than Jet. Of course, actually getting 255 concurrent users working
against a single fileserved .mdb is a trick which has escaped me over the
years <grin>. The record I have heard of in the ms-access ng is 110, some
years ago.

As with what you say about FM, Access handles concurrency seamlessly and
conversion to an RDMBS from a Jet backend can be painless, but - as with
FM - it depends upon the quality of the original design and implementation.
Access can be made to be a pile of festering dingoes kidneys, if the
programmer is inexperienced or has a diabolical mindset.

I guess anyone familiar with the quirks and advantages of either the FM or
Access development environment could put together a good solution for a
given problem, although the specifics of the implementation may diverge due
to the nature of the tools available.

To me, the two greatest reasons I am able to earn money with Access are:
1. It is already installed on so many millions of PCs around the world
2. The report writer.

I am a great supporter of cross platform and open source projects, but if a
customer wants to pay me to build (or, more often, fix up someone else's) MS
Access database applications, I am happy to oblige.  "8-)

To me the big problem most end users have is that they believe the writing
on the box which seems to tell them "You too can be a database designer.
Amaze your friends and entertain your boss by automating all your office
problems with our gee-whizz Product X !!".

I believe a competent database developer would be able to build a competent
application using either Access or FM (given adequate knowledge ofthe
tools); equally, either product could be abused into delivering said pile of
deceased dingo organs, if programmed with malice or ignorance.

At the end of the day, the really important point is: did the customer get
value for money? If yes, then the tools used to deliver that value seem
unimportant. If no, then the blame is with the developer, not the tool.

Just my $0.02, after lurking here for a couple of days.

Kind regards,
Doug

--
Remove the blots from my address to reply


0
Doug
6/25/2004 1:37:20 AM
Albert D. Kallal wrote:

>>If you are using FM developer to put together standalone runtime apps,
>>then yes you get your packaged installer to install the database and
>>database engine, and what not else.
> 
> 
> Yes, and so is ms-access that way. However, OFTEN you are MUCH better off to
> setup where and what folder the document will go into:
> My actual point here is that most of the time, you simply "copy" the
> application to each pc, and place it anywhere you want. However, the install
> tools are soo nice, that instead of telling you hey, here is this file, put
> it in my documents, I am using the installer to eliminate this SIMPLE task.
> 
> My point is that the installer is SOO easy, that I now even use it in place
> of what would be a simple file copy. The reasons are:
> 
>     It creates a directory for the target file in one of standard folders
> (my documents, my applications, my desktop etc).
> 
>     It makes a entry in the add/remove program in the control panel (so now
> users can remove the file) More important tech support can remove the
> application also

The last thing *I* want to do is run an installer complete with with an 
'add remove program icon' everytime you send me an MSOffice document.

But if you want to create an installer for a single file that really 
just needs to be dragged wherever the user wants to run it from ... then 
ok... sure. Personally I'd rather see it in the my documents folder 
where its more likely to be backed up, then in the program folder. (This 
assuming a single user solution where the 'data' is stored locally -- in 
a multiuser setup there is no reason to put anything other than 
filemaker on the local hard drive in the vast majority of cases.)


> 
>     It means support staff etc can assume, and know what directory the file
> is in.
> Are you telling me that you actually use the FM installer in place of simple
> file copy? (that was/is my point here!). In other words, I not even talking
> about installing the runtime system, but simply using that installer in
> place of what would be a simple file copy. I don't want to have to write up
> bunch of instructions as to where to place a simple stupid file. Again, what
> was issue here is how do you mange and deploy software to each pc. The
> question was in regards to support, and deployment. If people as a general
> rule use the FM installer in place of what is a simple file copy, then I am
> surprised
> 

Actually in most cases the user doesn't do *anything* at all. The file 
gets dropped on the server, and the user opens filemaker, selects open 
remote, selects the database from the list of available databases, and 
that's it.

There doesn't have to be a client side install of *any* solution file(s) 
in most cases.

But yes, if I wanted to put the solution files into a trivial installer 
wrapper then its easy, there are a zillion freeware installers that are 
dead simple to use... and that's if i dont feel like buying FM developer.
0
42
6/25/2004 1:43:01 AM
David W. Fenton wrote:


> The problems of deploying updates to the client workstation are
> pretty minor. 

Minor vs Nonexistent.

> It's interesting if FM has managed to make sharing the front end
> file safe and reliable. 

To paraphrase... "this is so basic to filemaker that its hard to imagine 
it not being so."


> I still wouldn't do it, though, as I'd always want the development
> and depolyed copies to be different. 
> 

Having the 'front end' to the database on the server has nothing to do 
with having separate 'development' and 'deployed copies'. You can do 
*both* at the same time. Just because your users are connecting to a 
front end hosted on a server doesn't mean that you can't also have a 
separate development version.
0
42
6/25/2004 1:49:25 AM
David W. Fenton wrote:


>>>>You can put the database tables in one or more files, and put the
>>>>front end layouts and scripts in one or more different files. You
>>>>can have multiple front ends accessing the same files.
>>>
>>>Yes, that's exactly what you can do in Access.
>>
>>>Can FileMaker do the same?
>>
>>Actually I *was* talking about FM.
> 
> 
> And my point should be clear: all the things you've said are FM
> advantages are also available (and pretty standard stuff) in Access. 

Obviously there's been a failure to communicate. I responded to an 
implication that FM _couldn't_ do this. Nobody ever said it was a 
revelation, or that access couldn't. Nobody has claimed these are 
filemaker 'advantages'!

The lack therof are simply no longer filemaker 'disadvantages'.

> 

> I think it's pretty clear here that people are claiming for FM as
> exclusive capabibilities features that Access has offered for more
> than ten years. 

I'd say that is as clear as mud.

If that's what you're reading then we need to stop, take some deep 
breathes, and start over. Nobody has claimed that any of this is 
exlcusive to FM. In actual fact the claim is that FM7 has finally 
corrected a long standing weakness... specifically that of not being 
able to properly separate code and data.

I regret that this was not clear. Are we on the same page now?


> I'm not really wanting to be combative here, because I'm interested
> in FM. 
> 
> But please, let's keep the discussion on the level that reflects
> actual kowledge of the competition. I've not tried to say anything
> about what FM can and can't do except if I've researched it. 
> 
> Please give us Access users the same courtesy in this discussion.

Given how badly my post was misunderstood, I'm not going to take offense 
to this backhanded insult. For what its worth, I'm quite well versed in 
writing access applications (against servers even).
0
42
6/25/2004 2:03:55 AM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwbqp.117mh021eivpxcN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> You mean, I can paste this into FM:
>> 
>> SELECT Field1, Field2, Field3
>> FROM MyTable
>> WHERE Field1>0
>> ORDER BY Field3, Field2 DESC 
>> 
>> and it will return data?
> 
> Yes.
> 
> That is, I wouldn't use Paste, I'd use Set Field and build the
> SELECT statement using calculation functions. I'd probably store
> my parameters in fields so they could be dynamically changed
> without having to re-program the entire thing.  Then a script
> command transmits the whole thing to the SQL database using an
> ODBC driver. 
> 
> The return of data is typically much faster than even a native FM
> find. Don't blink.

But it only works with ODBC data?

That is, not with FM's own data?

>> > I've only done very simple SQL queries in FM to pull data out
>> > of (MS-SQL) tables, and haven't ever needed to push data back,
>> > but that's also possible.  I'd say one's ability to write such
>> > queries would be limited by one's SQL skills, rather than by
>> > FM.  One writes the query into a global text field (usually
>> > with a script, using parameters entered in fields) and then
>> > implements the Send SQL script step to execute it.
>> 
>> Yet, Access provides a full SQL editor that allows you to write
>> SQL without needing to know SQL. 
>> 
>> Surely that's more flexibility than you describe FM as providing.
> 
> Well, let's not pretend that writing simple queries is really that
> hard. I had far more trouble getting the darn syntax right for
> identifying the table properly in the statement than getting the
> WHERE to work.  (don't ask me why "MyTable" didn't work, it HAD to
> be "MyDatabase_MyTable")  
> 
> There are FM tools that will write your SQL for you, at reasonable
> cost. It's not part of the basic app because very few people, at
> this point, require it.

Well, that's because FM doesn't require it, it's only required
without outside data sources. Right? 

>> And it also sounds like you are only passing through SQL to the
>> back-end database engine, and FM itself doesn't do SQL with its
>> own database engine.
> 
> Um no. Nobody ever said it did. The FM database engine is
> proprietary. One can pull & push data out of and into SQL tables,
> which means FM can act as either a front end to a SQL system, or
> just share data among different systems within an enterprise.
> Perhaps not surprisingly, sometimes companies want small discrete
> systems built in FM, NOT SQL, because it's easier, cheaper and
> more flexible to develop and maintain. 

But can I build a Filemaker application storing the data in FM's
native data format and use SQL to populate forms, and so forth? 

Or is SQL only available via ODBC drivers?

> Also, sometimes there are things we can do in FM that the SQL
> folks simply don't want to approach. We've got an enterprise
> system in place that interacts with Timberline accounting, which
> is based in Pervasive SQL. When we told the Timberline
> support/engineers what the (complex and idiosyncratic) structure
> of the company's bonus and commissions reports is, they just said
> "we can't do that."  So we did it in FM.  

This is not an unusual story. After a management change, a client of
mine abandoned their Access system, which had been running in the
NYC and London offices as well as in the home offices of two
subcontractors (all data shared via Jet replication), in favor of a
web-based system that didn't really coordinate data between the
different sites and couldn't support the home office users, had
fewer features and cost about 3 times as much. I helped out some in
getting the data from the Access app imported into their new app. In
the process, the developers saw my app and asked the customer "why
are you abandoning this great application for what we are providing,
which doesn't do as much?" This wasn't said to me -- it was said to
someone who was neutral in the situation and just passed it onto me. 

I think it's highly unlikely that there's anything FM can do in
terms of assembling a data set that cannot be done in SQL. SQL is
extremely powerful. Maybe the SQL dialect of Pervasive SQL makes it
hard, but I strongly doubt it is impossible, just that the people
you were talking to didn't know how to do it. 

But, again, I've heard the same kinds of things from DBAs when they
look at the kinds of complex Access apps that the people in
comp.databases.ms-access produce on a daily basis. 

We're not talking about point-and-click Access applications, just as
I'm sure you're not in regard to FM. 

>> Access allows you to write pass-through queries that are handed
>> off to the server for processing. But it allows you to use SQL
>> against every single data source you have available to you. In
>> other words, you have one method for your data retrieval
>> (obviously, with variations depending on the back end's SQL
>> dialect), one that is universal in the world of databases.
> 
> Really? Even those that don't support SQL? Like, say, Quickbooks?

Yes. If it's got an ODBC driver, you can use SQL.

You can use SQL against Excel spreadsheets, against tab-delimited
text files. 

> FM can connect directly to it, using a plugin. . . .

No plugins needed other than the ODBC driver. I would assume that FM
is also using ODBC. 

> . . . While FM has many
> methods of data retrieval, I see that as a feature, not a
> weakness.  One size does not fit all, and one method of data
> retrieval will certainly fail at some point. The entire world is
> not SQL, nor is it Windows. 

???

The entire world *is* SQL.

I'm not talking about SQL Server.

I'm talking about Structured Query Language, which exists as a
standard, well-defined language independent of any particular
implementation in any particular database engine. 

> If you want to really blow your preconceptions all to hell, go to
> www.servoy.com.   It's what I use when SQL is the preferred data
> storage tool, and when I want a nice FM-like front end,
> crossplatform, with massive capacity.

What the hell are you talking about "SQL is the preferred data
storage tool?" SQL is a language, not a database engine. 

> FM isn't always the correct tool, but often it is.

I don't know exactly what any of your post means now that it's clear
you really don't have a clue what SQL is. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 2:06:02 AM
42 <42@nospam.com> wrote in news:FqLCc.891642$Ig.650726@pd7tw2no:

> But yes, if I wanted to put the solution files into a trivial
> installer wrapper then its easy, there are a zillion freeware
> installers that are dead simple to use... and that's if i dont
> feel like buying FM developer. 

But what you're basically saying is that there's no difference in
ease of deployment between the two products. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 2:08:11 AM
FMP is what it is....If it does not fit your needs move on....MySql will
handle 600+ web hits at the same time. FMP handles a web hit approx a
sec....depends on your needs.



"Chris Brown" <cbrown@medicine.adelaide.edu.au> wrote in message
news:40db6169$1@yorrell.saard.net...
> NB wrote:
> >>VB. But then again, 4D has an extensive language too. I would sooner use
> >>4D than Access if I wanted a programming-based database. And 4D is cross
> >>platform too. I really don't see the draw to Access, other than people
> >
> >
> > I heard of 4thD before but never had time to take a long look.
> > Has anyone here tried it? Please give some comments too, particularly
> > in comparison to the more popular Access and FM.
> >
> > Thks
> >
> > NB
>
>
> 4D is definately worth a look; had FM7 been much longer to release, I
> would have migrated. FM7 now offers a number of things 4D has had for
yonks.
>   Free for academia too
>
>
> Chris Brown
> Neurosurgery
> University of Adelaide
>


0
Jennie
6/25/2004 2:12:44 AM
"James L. Ryan" <taliesinsoft@mac.com> wrote in message
news:0001HW.BD00A0B500031F34F03055B0@news.prodigy.net...
> On Thu, 24 Jun 2004 06:16:18 -0500, rkc wrote
> (in article <6KyCc.114965$j24.5148@twister.nyroc.rr.com>):
>
> [responding to my having stated that in the late seventies I had twenty
years
> computing experience]
>
> > What were you working on in 1958,  Great Gramps?
>
> My first computing work  was on the AN/FSQ-7, a vacuum tube computer built
by
> IBM especially for use in the SAGE air defense system.

The late, great Ronald Reagan would have been proud of you.



0
rkc
6/25/2004 2:15:11 AM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwcuj.2620kz1ju9hwvN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> Of course, it's rather hard to exceed what Access/Jet can do,
>> unless you've got a large number of users (over 50) and/or high
>> concurrency issues.
> 
> FM Server allows up to 250 concurrent LAN users. . .. 

Access/Jet theoretically allows 255, but that's not a practical
limit. 

> . . . A seat must be
> licensed for each client, but otherwise no additional costs.
> Larger installations split files and share the load over several
> servers. 

With a runtime installation, there are no per-seat licensing fees
with Access/Jet. 

If you need more than Jet can handle as a back end, the MSDE is
included and can be distributed with the runtime, but it's limited
to 5 simultaneous connections. That's not as bad as it sounds if you
are efficient with your connections, but I wouldn't want to try to
support more than 15 or 20 users in that scenario. 

So, basically, what I'm saying is that with an Access application,
per-seat licensing fees kick in only when you've exceeed the
abilities of the native db engine (i.e., Jet). 

You seem to be saying that per-seat fees kick in sooner than that
with FM's native db engine. 

> There are no "concurrency issues" with FM. It seamlessly handles
> record locking between clients. This has always been a feature of
> FM networking, there is no programming whatsoever required to
> ensure editing integrity. 

Er, do you know what "concurrency" means? It means contention for an
edit lock on a single record. If two users try to edit the same
record in FM, that contention has to be resolved. You can't
magically make the issue go away. 

Now, with page-level locking instead of record-level locking, you
increase the chance of contention issues, because it's a larger
block of data that gets locked, but there is a trade-off in
performance that's the inverse of the granularity of locking (i.e.,
the bigger the locked block, the higher the performance). 

And, of course, this is not strictly an Access issue, as what really
happens depends on which db engine you're using to store your data.
Jet gives you one set of concurrency issues, and MSDE/SQL Server
gives you another. A server-based db engine should have reduced
concurrency problems because there's a shorter roundtrip between the
server process and the data file. 

But the problem doesn't just go away -- you always have to deal with
it. It's just less of an issue with fewer users, and less of an
issue with fewer writes and less of an issue with fewer updates and
more appends, and so forth. 

>> FM provides a seamless migration to the server, or at least I
>> assume it's as easy as moving to the server version, right?
> 
> Yes, generally, if one has paid attention to proper solution
> design. . .. 

Aha. So it's not just transparent. Someone else said that migrating
from Jet to MSDE/SQL Server was not transparent and implied that
there were no such redesign issues with FM. So what you're saying is
that the situation with FM is pretty much the same: if you design
for the migration on the front end, it can be pretty painless. 

> . . . I'm assuming Access has some of the same issues, but
> perhaps not. . . .

No, it certainly has those issues. I'd be surprised if FM had *not*
had such issues! 

> . . . There are particular behaviors of certain elements in
> FM which could trip an inexperienced developer in moving from
> peer-to-peer shared files to a network-hosted version. 

It's exactly the same in Access. And, indeed, the sample databases
and help files tend to not give very good examples for efficient
multi-user databases. 

> But given proper design from the outset there should be zero need
> to rebuild or reprogram files for server hosting.

With Access, you don't get zero need, but you can minimize the
difficulties by designing with client/server migration in mind. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 2:17:17 AM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwd4b.16i54x9mz7b7cN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> Can FM use library databases, i.e., a FM database with shared
>> objects that can be used by other database applications
>> transparently?
> 
> No. FM objects are not separable from the files themselves. I'd
> say this is the biggest drawback of FM, the intermingling of data
> and code. :/ 
> 
> We hates it, we do. But on the other hand, I suspect a great deal
> of the "ease of use" comes from this structure.

Well, you have to be an advanced programmer to deal with the level
of separation I was talking about. Not too many developers do it. 

I sometimes use it for my personal function library, so that I can
deliver it to the client for use but with no source code. 

Of course, what you say about intermingling seems to contradict what
some of the other FM friends have said -- they say it's easy to
separate them. I assumed this was with the server version, though,
where you have a file of data that the server deals with and then
your layouts file that connects to the server data. 

Is that close?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 2:20:19 AM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwdb0.af4krnpf5o3xN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> I don't see anything about it on the Filemaker website in regards
>> to SQL Server 7. I do see that there is an ODBC driver provided,
>> and you could then use SQL from another application to manipulate
>> data in Filemaker. 
>> 
>> But can you, within the Filemaker UI, use SQL to retrieve data
>> for populating forms and listboxes and reports and the like? 
>> 
>> It doesn't look that way to me. I used Google to search
>> Filemaker.com, using these keywords for the search: 
>> 
>>  SQL site:filemaker.com -"sql server" "filemaker 7"
> 
> Well, the shoe's on the other foot here. You're clearly not even
> marginally familiar with FM.  FM objects are similar but not
> identical to other database ojbects.  It's a consequence of the
> integration of data and coding which plagues all advanced FM
> users. 

Well, no, I haven't claimed any familiarity with FM at all. That's
why I've asked all these questions that few seem interested in
answering. 

> SQL data, once retrieved from SQL sources in the FM files, . . .

I'm not talking about SQL data. I'm not talking about data stored in
a database engine that has its own SQL interface. 

I'm talking about SQL as a data retrieval language, not a database
engine. 

> . . . can be
> manipulated the same as any other data, of course. It can appear
> in "found sets" (=queries) and on layouts (=forms), in value lists
> (=listboxes) and in reports (=query +form) which are basically
> layouts structured to present the data as required by the user.

But can you write SQL to retrieve it, and store that SQL in the
objects so that they are populated with SQL? 

> One does not use SQL statements WITHIN FM. . . .

That answers my question.

And it's the answer I expected.

And it's a problem.

You say that FM objects is different from all other database front
ends. And this is one of those ways. 

And I would argue that it's not a *good* way, because it makes it
harder for people who are familiar with SQL in some depth from
easily manipulating in FM. 

> . . . In fact, FM cannot act
> as an ODBC datasource for itself.  In practical tests, FM is a
> piss-poor datasource for an ODBC connection when the returned
> dataset is more than a few records. FM itself will not tell you
> this, but while a SQL query from FM to pull records in can be
> blazing fast, any ODBC connection coming in is going to crawl.

But the articles I cited on the Filemaker website seems to recommend
exactly that approach as the way around FM's lack of internal SQL,
with the argument that you can manipulate FM's data via ODBC with
the SQL-friendly tool of your choice. 

> FM is much better at user interface and building business rules
> into software . . .

Ever heard of two-tier and three-tier application design?

> . . . than it is as a raw dataholder and number cruncher. 
> It's not the tool to be digging into with SQL. It's the go-between
> for innumerable other data systems in an enterprise, rather than
> the preferred data repository for huge data loads.

Is it possible to build a two-tier or three-tier application without
using a non-FM data store? 

Or do the business rules have to be encoded in the FM application?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 2:25:50 AM
Tony Toews wrote:

> "K&V P" <random_characters@shaw.ca.invalid> wrote:
> 
> 
>>7 years ago, I spent nearly 20 hours extracting data from a DOS database for a
>>local church because they needed to switch away from the custom solution they
>>were using due to space limitations imposed by Mr. Gates.
> 
> 
> Umm, IBM were responsible for the 640kb limitation as that is hardware.

Umm...no... by the time the mighty 80286 rolled out there was enough 
hardware support in the intel (not ibm) chip to support an OS that could 
exceed the 640k limit.

Its was Gate's "MS DOS" with its legacy (at that time already) operating 
system that retained the limit.

Hence, all the 'DOS extenders' that were released in that era. The 
hardware could do it... DOS couldn't. And the software most assuredly 
belonged to Gates.
0
42
6/25/2004 2:29:49 AM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbf5mu$otl$1@zcars0v6.ca.nortel.com: 
> 
> 
>>David W. Fenton wrote:
>>
>>
>>>Please explain how one would use a 4GB field.
>>
>>To store binary data.
>>- archives of image sets or other large files
>>- boot disk images for lab computers
>>- video footage
> 
> 
> Why would you store any of this data in a field of a record in a
> data table and not in the file system, with a pointer to that stored
> in the database? 
> 
> The point is not that there isn't data of that size, since there
> quite obviously is. The point is justifying why you'd store it in
> the data table. 
> 

Why support binary data all?? All binary data can be handled like this 
after all. Yet all databases worth anything can hold binary data.

The field size limit has to be something, if it was too small everyone 
would jump up and down saying it wouldn't meet their needs. How can it 
be 'too big'? Bottom line is, for the forseeable future, when you look 
at the field size limit for FM you won't be checking off the inadequate box.
0
42
6/25/2004 2:37:43 AM
On Thu, 24 Jun 2004 21:15:11 -0500, rkc wrote
(in article <PULCc.115341$j24.62518@twister.nyroc.rr.com>):

[in response to my stating that I was involved in the late 50's with the SAGE 
air defense system]

> The late, great Ronald Reagan would have been proud of you.

During my period with SAGE the U.S. presidents were IKE and JFK, and, yes, I 
would like to think that both of them were proud of my dedication to my work.


-- James L. Ryan -- TaliesinSoft

"My dog never came across a bush he didn't like!"

0
TaliesinSoft
6/25/2004 2:39:52 AM
Lyle Fairfield wrote:

> 
> Are you saying that FM is for the incapable?

After all everybody knows real men use assembly language! C is for the 
weak. And 'scripting'? What's that? A pastime for hairless monkeys???

The scriptmaker in FM is weaker than access. Its also faster to build 
scripts with. Its a tradeoff. You trade expressive power for speed of 
development... if it turns out fm has the expressive power you need than 
using access scripts amounts to a waste of time and therefore money.

If fm doesn't have the expressive power you need then use access.

If access doesn't have the expressive power you need then write it in 
C++. The fact that C++ has more expressive power than access doesn't 
make access for the incapable... does it?

Its not really a complicated decision making process.
0
42
6/25/2004 2:47:16 AM
Saintor wrote:

> The worst thing - and it is still the same in FM7 - is the scriptmaker.
> This is really a child's toy.and un-professional.

This is what I don't understand.  What makes it unprofessional?  The 
fact that you can't use a text editor to change a script?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 2:51:06 AM
> I would certainly be interested in seeing any complex query that could not
> be duplicated in FileMaker.  Maybe "NB" will follow up with an example of
> his "stack (nested) query" that we could try to implement in FileMaker.

Here is Celko's Bill Of Materials (this is not a nested query, but the
nested set logic is interesting. If you're not familiar with the
nested set notion versus the more popular tree (adjacency) concept -
pls read about it):

Take a look at this (incomplete) chart

A(1)
|
|---------------------------------------------
|             |                               |
1 B(2)      1 C(3)                          1 D(4)
|             |                               |
|----------    -------------------------       ------
|          |         |         |        |            |
1 E(5)   2 F(6)   1 J(10)   2 K(11)   7 L(12)     2 W(23)
                               |
                               |
                             3 N(14)
                               |
                 --------------------
                |         |          |
             1 O(15)   5 P(16)    7 Q(11)      


Explanation: 
- To make 1 unit of product N, you need 1 of O, 5 of P, and 7 of Q
- To make 1 unit of product K, you need 3 of N, or in terms of "atomic
components" you need 3 of 0, 15 of P, and 21 of Q
- and so on ...
- The number in parentheses is the node number


One table: P
MemberID  LongInteger
MemberName  Text
ParentID  LongInteger
Qty  LongInteger
lft  LongInteger
rgt  LongInteger

MemberID MemberName ParentID Qty lft rgt
1	A		1	1	52
2	B	A	1	2	13
3	C	A	1	14	41
4	D	A	1	42	51
5	E	B	1	3	8
6	F	B	2	9	12
7	G	E	2	4	5
8	H	E	3	6	7
9	I	F	3	10	11
10	J	C	1	15	16
11	K	C	2	17	28
12	L	C	7	29	40
13	M	K	6	18	19
14	N	K	3	20	27
15	O	N	1	21	22
16	P	N	5	23	24
17	Q	N	7	25	26
18	R	L	2	30	39
19	S	R	2	31	38
20	T	S	3	32	37
21	U	T	4	33	34
22	V	T	1	35	36
23	W	D	2	43	50
24	X	W	1	44	45
25	Y	W	1	46	49
26	Z	Y	2	47	48

qryCelkoBOM :
SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
FROM P, P AS P_1, P AS P_2
WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between [P].[lft]+1
And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And (P_2.lft) Between
[P_1].[lft] And [P_1].[rgt]))
GROUP BY P_2.MemberName;

How would we do this in FM?
Remember that in this nested set example, plain SQL is much, much
faster than other methods (cursor/recordset)

Also, a question I asked in this thread: does FM do SQL?


NB
0
nickbose
6/25/2004 3:03:15 AM
David W. Fenton wrote:


> 
> Aha. So it's not just transparent. Someone else said that migrating
> from Jet to MSDE/SQL Server was not transparent and implied that
> there were no such redesign issues with FM. So what you're saying is
> that the situation with FM is pretty much the same: if you design
> for the migration on the front end, it can be pretty painless. 

There are two categories of things that can go wrong. Things pertaining 
to the migration between two engines, and things specific to multi-user 
solutions.

A single user FM solution going to multiuser FM needs to address the 
various extra things that can go wrong in multiuser systems.

The transition from JET to MSDE is more complicated. Not only do you 
have to deal with the 'multiuser issues', but you have to deal with a 
whole other category of issues with respect to differences between the 
JET and MSDE engines.

With FM with a well designed solution all you literally have to do is 
put the files on a server. JET->MSDE no matter how well thought out, 
will always be more painful than that.

> 
>>. . . I'm assuming Access has some of the same issues, but
>>perhaps not. . . .
> 
> 
> No, it certainly has those issues. I'd be surprised if FM had *not*
> had such issues! 
> 
> 
>>. . . There are particular behaviors of certain elements in
>>FM which could trip an inexperienced developer in moving from
>>peer-to-peer shared files to a network-hosted version. 
> 
> 
> It's exactly the same in Access. And, indeed, the sample databases
> and help files tend to not give very good examples for efficient
> multi-user databases. 


Sadly true. But then FMs sample databases aren't a model one should 
follow either :)

> 
>>But given proper design from the outset there should be zero need
>>to rebuild or reprogram files for server hosting.
> 
> 
> With Access, you don't get zero need, but you can minimize the
> difficulties by designing with client/server migration in mind. 

Exactly right.
0
42
6/25/2004 3:05:37 AM
"K&V P" <random_characters@shaw.ca.invalid> wrote in message news:<JZrCc.874213$Ig.666717@pd7tw2no>...
> "David W. Fenton"  wrote...
> > 4GBs in a single field? Why would anyone need that?
> 
> 
> "640k should be enough for anybody."
>                   - - Bill Gates, 1981
> 
> Maybe you're too young to remember where that one got us?
> 
> Kent

Hmm, I got to agree with Kent on this one. We may well need 4TB in a field one day

NB
0
nickbose
6/25/2004 3:09:46 AM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:FqLCc.891642$Ig.650726@pd7tw2no:
> 
> 
>>But yes, if I wanted to put the solution files into a trivial
>>installer wrapper then its easy, there are a zillion freeware
>>installers that are dead simple to use... and that's if i dont
>>feel like buying FM developer. 
> 
> 
> But what you're basically saying is that there's no difference in
> ease of deployment between the two products. 
> 

When deploying to an end user 'on their machine'. There is no 
difference. Correct.

But... FM deployments are typically strictly server side, and work 
*very* well that way. And its easier to do a server side deployment than 
any sort of client side deployment.

And while you can run Access like that, that isn't an ideal 
configuration for access. It is an ideal configuration for FM.

Now, in the real world, most access setups use a client side deployment, 
and most fm setups use a server side deployment. That means, in the real 
world, fm admins spend less time/effort/money dealing with deployment.

Is that a fair way to put it?
0
42
6/25/2004 3:11:33 AM
"James L. Ryan" wrote

 > Oops, I'm guilty of exaggeration. Correction,
 > the Q-7 originally came with 8 K 30 bit words
 > which was subsequently expanded to 72 K
 > 30 bit words.

Where did you work, James? I was at SDC in Santa Monica 1959 - 1960 and at
McChord AFB in Tacoma 1960 - 62 -- in Tacoma, I was actually assigned to the
Combat Center which had a Q-8 which did not have the expanded bank of
memory, but worked on the Q-7 as well. I'll bet I have my laminated Program
Code card to this day, if I looked hard enough.

Those words, I believe, were 32 bits... two "half-words" for simultaneous
calculation of X and Y coordinates, each one sign bit plus 16 data bits, but
an option for using them unsigned. A great idea, but calculating positions
was only a minor part of the system, so most of the time one of the
half-words went unused.

And, rkc, before you go all condescending on us, just remember that we kept
you and your parents safe from Soviet manned bombers during the "brink of
war" years of the Cold War. I've had an e-mail discussion with one of our
Russian (then Soviet) counterparts who "kept the Motherland safe from U.S.
manned bombers", too. We agreed that it was nice that we had each kept our
respective homelands safe. :-)

  Larry Linson


0
Larry
6/25/2004 3:14:48 AM
On Thu, 24 Jun 2004 22:14:48 -0500, Larry  Linson wrote
(in article <IMMCc.26647$a61.12854@nwrddc01.gnilink.net>):

> "James L. Ryan" wrote
> 
>  > Oops, I'm guilty of exaggeration. Correction,
>  > the Q-7 originally came with 8 K 30 bit words
>  > which was subsequently expanded to 72 K
>  > 30 bit words.
> 
> Where did you work, James? I was at SDC in Santa Monica 1959 - 1960 and at
> McChord AFB in Tacoma 1960 - 62 -- in Tacoma, I was actually assigned to the
> Combat Center which had a Q-8 which did not have the expanded bank of
> memory, but worked on the Q-7 as well. I'll bet I have my laminated Program
> Code card to this day, if I looked hard enough.
> 
> Those words, I believe, were 32 bits... two "half-words" for simultaneous
> calculation of X and Y coordinates, each one sign bit plus 16 data bits, but
> an option for using them unsigned. A great idea, but calculating positions
> was only a minor part of the system, so most of the time one of the
> half-words went unused.
> 
> And, rkc, before you go all condescending on us, just remember that we kept
> you and your parents safe from Soviet manned bombers during the "brink of
> war" years of the Cold War. I've had an e-mail discussion with one of our
> Russian (then Soviet) counterparts who "kept the Motherland safe from U.S.
> manned bombers", too. We agreed that it was nice that we had each kept our
> respective homelands safe. :-)
> 
>   Larry Linson
> 
> 

I was at SDC in Santa Monica in 59 and 60, and at Luke Air Force base outside 
of Phoenix in 61 and 62.  I wish I could remember the names of the people I 
worked for. 

As to the computer "words," 30 bits sticks in my mind. They were divided into 
two 15 bit halfs, a sign and 14 bits of value. I will admit I could be off by 
a bit for each half word here.

My particular specialty was being a primary maintainer of the SIDs module of 
the SAGE software, SIDs being the glop of code that drove the visual 
displays.

I don't recall a laminated programming card, but the one Q7 instruction I 
really remember is BPX (Branch to Positive Index) which was the "go to" of 
the Q7.

Please keep in touch, either on this newsgroup or by email. I have a strong 
sneaky that we probably have a number of friends or acquaintances in common.


-- James L. Ryan -- TaliesinSoft

"My dog never came across a bush he didn't like!"

0
TaliesinSoft
6/25/2004 3:29:12 AM
David W. Fenton wrote:

> Of course, what you say about intermingling seems to contradict what
> some of the other FM friends have said -- they say it's easy to
> separate them. I assumed this was with the server version, though,
> where you have a file of data that the server deals with and then
> your layouts file that connects to the server data. 
> 
> Is that close?

Close, but not exactly.  As for the intermingling, a FileMaker developer 
COULD completely separate things, but they would lose the ability to 
lose calculation type fields under some circumstances.  You don't have 
calc fields in Access -- which is fine -- but that means that you need 
to set calc'd variables by script.  One could do the same thing in 
FileMaker, but it adds a layer of complexity in the scripting that just 
usually is necessary.  So we opt to keep the calc fields and compromise 
on complete and total separation.

As for system configuration, I think you might misunderstand something. 
  If a developer wanted to, he/she could have an interface file that sat 
on a client machine.  But I don't see a lot of advantage with that.  In 
fact, the disadvantage is that if you needed to make any changes, you'd 
have to send each client a new copy of the interface file.

In FileMaker, all database files are generally hosted by FileMaker 
Server (or on the new FM Server Advanced, for web, XSLT, ODBC and JDBC 
services).  A client can connect to the server and see whatever files 
are being hosted and that are designated for that client to see.  A 
solution's main file might act as strictly an interface file, working in 
conjunction with other interface and/or logic and/or data files that are 
hidden on the server.  Keep in mind that all of these files have the 
same potential to incorporate multiple data tables, scripting, layouts 
(forms), reports -- it just depends on how the developer chooses to 
structure it.

Changes to any of the elements in each served file, including data 
structure, can be made on the live file (if desired) and users will 
immediately benefit from those changes.  Or, if preferred, a copy of the 
solution could be opened by a client off-line for development.  The 
database behaves (basically) the same regardless of whether it is hosted 
by the client or by the server.  The primary concern when moving a 
solution to Server is that it will now be a shared, multi-user solution 
and any potential record-locking issues need to be taken into 
consideration.  Generally, FileMaker handles the record-locking and 
releasing automatically without any additional scripting.  But one could 
inadvertantly lock a related record without realizing it if the 
developer didn't consider the way he was setting it up.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 3:34:40 AM
"David W. Fenton" wrote...
> Well, my experience tells me that it's never a good idea to store
> BLOB data in a proprietary database format. Instead, it's better to
> store in the file system, where you have security and backup at a
> completely different level.

It may or may not "never" be a good idea, but some people do it. It might make
more sense to those who work with a database that supports multiple platforms.
When compiling for non Windows computers, you can't rely on the exact nature of
the filing system to match up. An embedded item is where you left it and the
exact nature of the path is a non-issue.

My reference to security was more in the line of making sure the file doesn't go
anywhere without it's database. You can't always rely on an end user not to do a
global find for file-types and move / delete / rename something without knowing
exactly what it is. If it is embedded, they won't find it and can't remove it
unless you've designed a way for them to do that internally.

Kent


0
K
6/25/2004 3:44:14 AM
David W. Fenton wrote:
> lynn@NOT-semiotics.com (Lynn allen) wrote in
> news:1gfwdb0.af4krnpf5o3xN%lynn@NOT-semiotics.com: 
> 
> 
>>David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>>
>>
>>>I don't see anything about it on the Filemaker website in regards
>>>to SQL Server 7. I do see that there is an ODBC driver provided,
>>>and you could then use SQL from another application to manipulate
>>>data in Filemaker. 
>>>
>>>But can you, within the Filemaker UI, use SQL to retrieve data
>>>for populating forms and listboxes and reports and the like? 
>>>
>>>It doesn't look that way to me. I used Google to search
>>>Filemaker.com, using these keywords for the search: 
>>>
>>> SQL site:filemaker.com -"sql server" "filemaker 7"
>>
>>Well, the shoe's on the other foot here. You're clearly not even
>>marginally familiar with FM.  FM objects are similar but not
>>identical to other database ojbects.  It's a consequence of the
>>integration of data and coding which plagues all advanced FM
>>users. 
> 
> 
> Well, no, I haven't claimed any familiarity with FM at all. That's
> why I've asked all these questions that few seem interested in
> answering. 
> 
> 
>>SQL data, once retrieved from SQL sources in the FM files, . . .
> 
> 
> I'm not talking about SQL data. I'm not talking about data stored in
> a database engine that has its own SQL interface. 
> 
> I'm talking about SQL as a data retrieval language, not a database
> engine. 
> 
> 
>>. . . can be
>>manipulated the same as any other data, of course. It can appear
>>in "found sets" (=queries) and on layouts (=forms), in value lists
>>(=listboxes) and in reports (=query +form) which are basically
>>layouts structured to present the data as required by the user.
> 
> 
> But can you write SQL to retrieve it, and store that SQL in the
> objects so that they are populated with SQL? 
> 
> 
>>One does not use SQL statements WITHIN FM. . . .
> 
> 
> That answers my question.
> 
> And it's the answer I expected.
> 
> And it's a problem.
> 
> You say that FM objects is different from all other database front
> ends. And this is one of those ways. 
> 
> And I would argue that it's not a *good* way, because it makes it
> harder for people who are familiar with SQL in some depth from
> easily manipulating in FM. 

LisP is very difficult for your run of the mill procedural programmer to 
wrap his head around (that would be nearly all programmers), but it is 
very good at doing what it was designed for, and it can do all the 
procedural things you might like... if you can wrap your head around 
doing everythings recursively.

FM is like lisp, except that where thinking recursively is hard for most 
people, dealing with Filemaker is intuitive and easy for most people. In 
fact the only bright people who seem to have trouble with it are those 
with closed minds who cannot concieve of interacting with data except 
via SQL queries, and keep trying to talk SQL to FM, when it just doesn't 
work that way.

> Is it possible to build a two-tier or three-tier application without
> using a non-FM data store? 
> 

FM can communicate with itself as a 'data repository' just fine. The 
performance problems only arise when a *non-FM* tier tries to access FM 
as the data store.

Thus a 2 tier is doable, if its a complete FM site with both tiers on FM.

For a 3 tier, I would say that FM is not suitable. Their is no 
*efficient* way to separate business logic from the  presentation 
interface. It could be done, I suppose, but I wouldn't recommend it to 
anybody... definately a square peg in a star shaped hole.

But then that is why FM is touted as a solution for workgroups or as a 
front end to enterprise systems,. It isn't suited to be a data 
repository for non FM clients, nor is it suitable for dedicated tier 2 
work at all. In an enterprise 3-tier application its place is really 
only at the front end presentation hitting business logic server or data 
repository directly. It never claims otherwise.
0
42
6/25/2004 3:49:44 AM
"Larry Linson" <bouncer@localhost.not> wrote in message
news:IMMCc.26647$a61.12854@nwrddc01.gnilink.net...

> And, rkc, before you go all condescending on us, just remember that we
kept
> you and your parents safe from Soviet manned bombers during the "brink of
> war" years of the Cold War. I've had an e-mail discussion with one of our
> Russian (then Soviet) counterparts who "kept the Motherland safe from U.S.
> manned bombers", too. We agreed that it was nice that we had each kept our
> respective homelands safe. :-)

Come on, Larry. We all knew that all we had to do is hide under our
desks or the cafeteria tables and everything would turn out fine.




0
rkc
6/25/2004 4:08:06 AM
Doug Hutcheson <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au>
wrote:

> To me the big problem most end users have is that they believe the writing
> on the box which seems to tell them "You too can be a database designer.
> Amaze your friends and entertain your boss by automating all your office
> problems with our gee-whizz Product X !!".

Thus my entry into a large percentage of the projects I do. ;)  "We have
this database that our general manager/secretary/president's son-in-law
started, it's almost finished, it just needs a few things."

"Uh, no, what you have is a haphazard assemblage of
data-holders-meant-to-mimic-paper-forms, not a database. You have no
business logic, no error checking, no data integrity enforcement, no
security, an indefensible data structure, and damn little interface.
Let's talk about a REAL databa$e."

The incompetently started project is one of the major sources of
business for developers.  I expect the sticking point is going to be a
bit lower with 7 than it was in 6, but perhaps I underestimate the
ability of beginners to design an absolutely flat-file named
"Invoices2004.fp7."  Invoices2005 to follow. ;) 
> 
> I believe a competent database developer would be able to build a competent
> application using either Access or FM (given adequate knowledge ofthe
> tools); equally, either product could be abused into delivering said pile of
> deceased dingo organs, if programmed with malice or ignorance.
> 
> At the end of the day, the really important point is: did the customer get
> value for money? If yes, then the tools used to deliver that value seem
> unimportant. If no, then the blame is with the developer, not the tool.

I absolutely agree. In fact, I now introduce myself to customers as
someone who will not COST them money, but will instead use database
tools to MAKE them money. And if the project can't either eliminate
costs or discover some previously uncaptured profitability in their
business, I tell them so and walk away.

But when someone posts on the newsgroup asking to compare features of FM
& X in a non-troll manner, we do try to answer. :)  Every tool has a
slightly different advantage, and differing disadvantages. One thing I
do know, from working with RealBasic, VB (a little bit), Servoy and FM,
FM is the most FUN. Fun is subjective, of course, but I find it so
anyway. There's no point in working with a tool you don't enjoy.  Not
even for the big bucks.

Lynn Allen
www.semiotics.com


FM 7 Tip of the Week: Field Behavior allows developers to choose entry
options like permitting entry into a field in Find mode but not Browse,
and whether a field is exited by Tab, Enter or Return keys (or all
three). No more scripts to "protect" fields!  
 
0
lynn
6/25/2004 4:09:58 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> Er, do you know what "concurrency" means? It means contention for an
> edit lock on a single record. If two users try to edit the same
> record in FM, that contention has to be resolved. You can't
> magically make the issue go away. 
> 
> Now, with page-level locking instead of record-level locking, you
> increase the chance of contention issues, because it's a larger
> block of data that gets locked, but there is a trade-off in
> performance that's the inverse of the granularity of locking (i.e.,
> the bigger the locked block, the higher the performance).


Er, are you always so rude?

Of course I know what concurrency means. In FM, when a user is editing a
field on a record, the second user to try to edit ANY field on that
record gets a message that "Username is editing this record. Please try
again."  The lock isn't released until the first user commits the record
by clicking outside any field or by leaving the layout or the file.

Any locked record can be viewed and read from, but not written to, by
any other user. It can participate in any found set for another user,
such as in a report, it can be exported, but not deleted.

There is no page-level locking in FM or locking of more than one record,
except in the very special circumstances where two users have the same
first record in a portal and one of them clicks into the first portal
row. In that case, both the child record and the parent record are
locked.

This all works because native FM data access is not transactional in
nature. Of course if you're working with web-enabled files and do have
to account for transactional access, it's a whole different ball game.
There are functions such as Status(CurrentModificationCount) that allow
a developer to judge if records have been modified between the current
user's request for the data and the push back into the data files.  Then
they have to do some programmatic resolution of conflicts, but in LAN
access, there are no concurrency issues. 

There are server settings to control how long users can remain connected
in the case of someone locking a record and leaving for vacation, to
prevent permanent lock inconveniencing other users.

FM doesn't "magically make the problem go away" nor did I claim that it
did. Instead, it resolves it with an extremely robust locking
arrangement that requires no effort on the part of the developer.

It just works, with any number of users.

Lynn Allen  
0
lynn
6/25/2004 4:09:58 AM
"TaliesinSoft" <taliesinsoft@mac.com> wrote in message
news:0001HW.BD010638001AE9FAF03055B0@news.prodigy.net...
> On Thu, 24 Jun 2004 22:14:48 -0500, Larry  Linson wrote
> (in article <IMMCc.26647$a61.12854@nwrddc01.gnilink.net>):
>
> > "James L. Ryan" wrote
> >
> >  > Oops, I'm guilty of exaggeration. Correction,
> >  > the Q-7 originally came with 8 K 30 bit words
> >  > which was subsequently expanded to 72 K
> >  > 30 bit words.
> >
> > Where did you work, James? I was at SDC in Santa Monica 1959 - 1960 and
at
> > McChord AFB in Tacoma 1960 - 62 -- in Tacoma, I was actually assigned to
the
> > Combat Center which had a Q-8 which did not have the expanded bank of
> > memory, but worked on the Q-7 as well. I'll bet I have my laminated
Program
> > Code card to this day, if I looked hard enough.
>
> I was at SDC in Santa Monica in 59 and 60, and at Luke Air Force base
outside
> of Phoenix in 61 and 62.  I wish I could remember the names of the people
I
> worked for.



I'm just glad to know there are developers even older than me out there
still...
"8-)
Doug (25 years in the industry as my second career, and counting...)

--
Remove the blots from my address to reply



0
Doug
6/25/2004 5:09:04 AM
"Lynn allen" <lynn@NOT-semiotics.com> wrote in message
news:1gfwjtc.19m4yee153pnk1N%lynn@NOT-semiotics.com...
> Doug Hutcheson <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au>
> wrote:
>
> > To me the big problem most end users have is that they believe the
writing
> > on the box which seems to tell them "You too can be a database designer.
> > Amaze your friends and entertain your boss by automating all your office
> > problems with our gee-whizz Product X !!".
>
> Thus my entry into a large percentage of the projects I do. ;)  "We have
> this database that our general manager/secretary/president's son-in-law
> started, it's almost finished, it just needs a few things."
>
> "Uh, no, what you have is a haphazard assemblage of
> data-holders-meant-to-mimic-paper-forms, not a database. You have no
> business logic, no error checking, no data integrity enforcement, no
> security, an indefensible data structure, and damn little interface.
> Let's talk about a REAL databa$e."
>
> The incompetently started project is one of the major sources of
> business for developers.  I expect the sticking point is going to be a
> bit lower with 7 than it was in 6, but perhaps I underestimate the
> ability of beginners to design an absolutely flat-file named
> "Invoices2004.fp7."  Invoices2005 to follow. ;)
> >
> > I believe a competent database developer would be able to build a
competent
> > application using either Access or FM (given adequate knowledge ofthe
> > tools); equally, either product could be abused into delivering said
pile of
> > deceased dingo organs, if programmed with malice or ignorance.
> >
> > At the end of the day, the really important point is: did the customer
get
> > value for money? If yes, then the tools used to deliver that value seem
> > unimportant. If no, then the blame is with the developer, not the tool.
>
> I absolutely agree. In fact, I now introduce myself to customers as
> someone who will not COST them money, but will instead use database
> tools to MAKE them money. And if the project can't either eliminate
> costs or discover some previously uncaptured profitability in their
> business, I tell them so and walk away.
>
> But when someone posts on the newsgroup asking to compare features of FM
> & X in a non-troll manner, we do try to answer. :)  Every tool has a
> slightly different advantage, and differing disadvantages. One thing I
> do know, from working with RealBasic, VB (a little bit), Servoy and FM,
> FM is the most FUN. Fun is subjective, of course, but I find it so
> anyway. There's no point in working with a tool you don't enjoy.  Not
> even for the big bucks.



Fun.
Oh, yes. Fun.
Hmmm .. I remember FUN.
Then I got to be a programmer.
Now I get to have so much FUN each day that it makes me swear and kick small
domestic animals.
....
.... hang on ...
.... that compile just worked ...
Hooray, the routine is finally finished!!
Tra la, tra lee - isn't computing fun?


Is that the kind of fun you were referring to?

<grin>

--
Remove the blots from my address to reply


0
Doug
6/25/2004 5:24:55 AM
Lynn allen wrote:
> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> > Er, do you know what "concurrency" means? It means contention for an
> > edit lock on a single record. If two users try to edit the same
> > record in FM, that contention has to be resolved. You can't
> > magically make the issue go away. 
> > 
> > Now, with page-level locking instead of record-level locking, you
> > increase the chance of contention issues, because it's a larger
> > block of data that gets locked, but there is a trade-off in
> > performance that's the inverse of the granularity of locking (i.e.,
> > the bigger the locked block, the higher the performance).
> 
> Er, are you always so rude?

Yes, he is. Calm objective discussion is not possible. I tried and
(he) failed. Its just a troll.

cheers, Bernd
0
Bernd
6/25/2004 11:39:29 AM
Saintor wrote:

> The worst thing - and it is still the same in FM7 - is the scriptmaker.
> This is really a child's toy.and un-professional.

That "child's toy" has helped me earn thousands of dollars. By 
definition, that would make it professional.
0
Kevin
6/25/2004 1:04:21 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbf5mu$otl$1@zcars0v6.ca.nortel.com: 
> 
> 
>>David W. Fenton wrote:
>>
>>
>>>Please explain how one would use a 4GB field.
>>
>>To store binary data.
>>- archives of image sets or other large files
>>- boot disk images for lab computers
>>- video footage
> 
> 
> Why would you store any of this data in a field of a record in a
> data table and not in the file system, with a pointer to that stored
> in the database? 

Ease of archiving, perhaps? A file system is just a specialized database 
- one can be as good as another.

Regardless, what is your cut-off for moving data outside the database? 
A 4GB limit basically means there is no practical limit. That is the point.
0
Kevin
6/25/2004 1:09:07 PM
There is a post on ZDNet by someone who specializes in Oracle and SQL 
apps, but has grown to really like FileMaker for some of his apps.  It's 
sort of on topic with this thread.  At:

http://techupdate.zdnet.com/techupdate/stories/main/tools_for_the_rest_of_us.html


David W. Fenton wrote:
> lynn@NOT-semiotics.com (Lynn allen) wrote in
> news:1gfwdb0.af4krnpf5o3xN%lynn@NOT-semiotics.com: 
> 
> 
>>David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>>
>>
>>>I don't see anything about it on the Filemaker website in regards
>>>to SQL Server 7. I do see that there is an ODBC driver provided,
>>>and you could then use SQL from another application to manipulate
>>>data in Filemaker. 
>>>
>>>But can you, within the Filemaker UI, use SQL to retrieve data
>>>for populating forms and listboxes and reports and the like? 
>>>
>>>It doesn't look that way to me. I used Google to search
>>>Filemaker.com, using these keywords for the search: 
>>>
>>> SQL site:filemaker.com -"sql server" "filemaker 7"
>>
>>Well, the shoe's on the other foot here. You're clearly not even
>>marginally familiar with FM.  FM objects are similar but not
>>identical to other database ojbects.  It's a consequence of the
>>integration of data and coding which plagues all advanced FM
>>users. 
> 
> 
> Well, no, I haven't claimed any familiarity with FM at all. That's
> why I've asked all these questions that few seem interested in
> answering. 
> 
> 
>>SQL data, once retrieved from SQL sources in the FM files, . . .
> 
> 
> I'm not talking about SQL data. I'm not talking about data stored in
> a database engine that has its own SQL interface. 
> 
> I'm talking about SQL as a data retrieval language, not a database
> engine. 
> 
> 
>>. . . can be
>>manipulated the same as any other data, of course. It can appear
>>in "found sets" (=queries) and on layouts (=forms), in value lists
>>(=listboxes) and in reports (=query +form) which are basically
>>layouts structured to present the data as required by the user.
> 
> 
> But can you write SQL to retrieve it, and store that SQL in the
> objects so that they are populated with SQL? 
> 
> 
>>One does not use SQL statements WITHIN FM. . . .
> 
> 
> That answers my question.
> 
> And it's the answer I expected.
> 
> And it's a problem.
> 
> You say that FM objects is different from all other database front
> ends. And this is one of those ways. 
> 
> And I would argue that it's not a *good* way, because it makes it
> harder for people who are familiar with SQL in some depth from
> easily manipulating in FM. 
> 
> 
>>. . . In fact, FM cannot act
>>as an ODBC datasource for itself.  In practical tests, FM is a
>>piss-poor datasource for an ODBC connection when the returned
>>dataset is more than a few records. FM itself will not tell you
>>this, but while a SQL query from FM to pull records in can be
>>blazing fast, any ODBC connection coming in is going to crawl.
> 
> 
> But the articles I cited on the Filemaker website seems to recommend
> exactly that approach as the way around FM's lack of internal SQL,
> with the argument that you can manipulate FM's data via ODBC with
> the SQL-friendly tool of your choice. 
> 
> 
>>FM is much better at user interface and building business rules
>>into software . . .
> 
> 
> Ever heard of two-tier and three-tier application design?
> 
> 
>>. . . than it is as a raw dataholder and number cruncher. 
>>It's not the tool to be digging into with SQL. It's the go-between
>>for innumerable other data systems in an enterprise, rather than
>>the preferred data repository for huge data loads.
> 
> 
> Is it possible to build a two-tier or three-tier application without
> using a non-FM data store? 
> 
> Or do the business rules have to be encoded in the FM application?
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 1:24:41 PM
"NB" <nickbose@softhome.net> wrote in message
news:5240fc76.0406241903.51a3813c@posting.google.com...

<SNIP>

>
> qryCelkoBOM :
> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
> FROM P, P AS P_1, P AS P_2
> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between [P].[lft]+1
> And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And (P_2.lft) Between
> [P_1].[lft] And [P_1].[rgt]))
> GROUP BY P_2.MemberName;
>
> How would we do this in FM?

I am not familiar with SQL, therefore I have no idea what this means.  If
you posted the results of your query, I might be able to respond.


0
Glenn
6/25/2004 3:26:40 PM
NB wrote:


> qryCelkoBOM :
> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
> FROM P, P AS P_1, P AS P_2
> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between [P].[lft]+1
> And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And (P_2.lft) Between
> [P_1].[lft] And [P_1].[rgt]))
> GROUP BY P_2.MemberName;
> 
> How would we do this in FM?

Map out each relation in Define Database with table_groups P_1, P_2. 
Then place two fields in the layout: text field P_2::MemberName and 
calc field = Exp(Sum(Log(P_1::Qty))) - sort the layout by 
P_2::MemberName and the new calc field and you're done.
0
Kevin
6/25/2004 3:51:47 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwjtc.19m4yee153pnk1N%lynn@NOT-semiotics.com: 

> But when someone posts on the newsgroup asking to compare features
> of FM & X in a non-troll manner, we do try to answer. :)  Every
> tool has a slightly different advantage, and differing
> disadvantages. One thing I do know, from working with RealBasic,
> VB (a little bit), Servoy and FM, FM is the most FUN. Fun is
> subjective, of course, but I find it so anyway. There's no point
> in working with a tool you don't enjoy.  Not even for the big
> bucks. 

Well, props to you, Lynn, for being a good egg in this discussion.
I've learned quite a bit (even though I may sound indignant at times
-- regulars in CDMA will tell you that I sound that way a lot ;). 

I'm also very interested in Servoy. I downloaded the demo and will
be investigating it. I fear it will be slow, being entirely
Java-based, but am hoping it isn't. I don't relish learning Java,
but if it does what it says it does, it might really be the
cross-platform solution that those of us in CDMA who tried to start
our own open source project to replace Access were looking for. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 3:52:53 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfwkd3.x9x3x2i3x0txN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> Er, do you know what "concurrency" means? It means contention for
>> an edit lock on a single record. If two users try to edit the
>> same record in FM, that contention has to be resolved. You can't
>> magically make the issue go away. 
>> 
>> Now, with page-level locking instead of record-level locking, you
>> increase the chance of contention issues, because it's a larger
>> block of data that gets locked, but there is a trade-off in
>> performance that's the inverse of the granularity of locking
>> (i.e., the bigger the locked block, the higher the performance).
> 
> Er, are you always so rude?

I'm afraid I am. Sorry.

I get carried away.

> Of course I know what concurrency means. In FM, when a user is
> editing a field on a record, the second user to try to edit ANY
> field on that record gets a message that "Username is editing this
> record. Please try again."  The lock isn't released until the
> first user commits the record by clicking outside any field or by
> leaving the layout or the file. 

Pessimistic locking is your only option in FM? That's too bad. What
do you do if a user begins an edit on a record and walks away from
the computer? That means the second user can never edit the record. 

> Any locked record can be viewed and read from, but not written to,
> by any other user. It can participate in any found set for another
> user, such as in a report, it can be exported, but not deleted.
>
> There is no page-level locking in FM or locking of more than one
> record, except in the very special circumstances where two users
> have the same first record in a portal and one of them clicks into
> the first portal row. In that case, both the child record and the
> parent record are locked.

Basically, FM and Access/Jet are equivalent, then, though Access/Jet
defaults to page-level locking, while offering record-level locking
in Jet 4. 

But because Access also offers optimistic locking, page-level
locking works pretty well. 

I once tried writing an app with pessimistic locking and it was
pretty much a disaster. I reverted back to optimistic locking, and
write conflicts were not even an issue. 

> This all works because native FM data access is not transactional
> in nature. . . .

Nor is native Jet data. . .

> . . . Of course if you're working with web-enabled files and
> do have to account for transactional access, it's a whole
> different ball game. There are functions such as
> Status(CurrentModificationCount) that allow a developer to judge
> if records have been modified between the current user's request
> for the data and the push back into the data files.  Then they
> have to do some programmatic resolution of conflicts, but in LAN 
> access, there are no concurrency issues. 

That's an excellent feature. I have often wished Access had a flag
like that. Jet obviously provides the information somehow, as the
Access UI provides a visual indication that a record is locked and
non-writable, but it's not accessible programmatically. 

> There are server settings to control how long users can remain
> connected in the case of someone locking a record and leaving for
> vacation, to prevent permanent lock inconveniencing other users.

That's another good feature. Are the edits rolled back if the lock
exceeds the timeout? What feedback does the user get on that? That
is, does FM tell the user that their changes have been rolled back
because they waited too long to save them? 

> FM doesn't "magically make the problem go away" nor did I claim
> that it did. Instead, it resolves it with an extremely robust
> locking arrangement that requires no effort on the part of the
> developer. 
> 
> It just works, with any number of users.

Well, you have to deal with exactly the same issues as in Access --
the user is forced to deal with a write conflict, just as in Access
(though in Access you can program your own custom user interaction,
since the default Access write conflict dialog is Byzantinely
confusing). 

Based on what you've said, the advantages of FM over Access in
regard to concurrency are: 

1. a function to find out if a record is locked (or, at least,
modified since it was first retrieved?) 

2. the ability to roll back uncomitted changes by inactive users
after a specified timeout interval. 

Both of those things can be implemented in Access in code, but
neither is as efficient as having it in the database engine. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:01:28 PM
Bernd Bollman <bernd@hotmail.com> wrote in
news:cbh2th$vv7$07$3@news.t-online.com: 

> Lynn allen wrote:
>> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>> > Er, do you know what "concurrency" means? It means contention
>> > for an edit lock on a single record. If two users try to edit
>> > the same record in FM, that contention has to be resolved. You
>> > can't magically make the issue go away. 
>> > 
>> > Now, with page-level locking instead of record-level locking,
>> > you increase the chance of contention issues, because it's a
>> > larger block of data that gets locked, but there is a trade-off
>> > in performance that's the inverse of the granularity of locking
>> > (i.e., the bigger the locked block, the higher the
>> > performance). 
>> 
>> Er, are you always so rude?
> 
> Yes, he is. Calm objective discussion is not possible. I tried and
> (he) failed. Its just a troll.

Lynn provides lots of factual information to support her points.

You never did.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:02:06 PM
Kevin Hayes <me@here.com> wrote in
news:cbh80t$nh5$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Kevin Hayes <me@here.com> wrote in
>> news:cbf5mu$otl$1@zcars0v6.ca.nortel.com: 
>> 
>>>David W. Fenton wrote:
>>>
>>>>Please explain how one would use a 4GB field.
>>>
>>>To store binary data.
>>>- archives of image sets or other large files
>>>- boot disk images for lab computers
>>>- video footage
>> 
>> Why would you store any of this data in a field of a record in a
>> data table and not in the file system, with a pointer to that
>> stored in the database? 
> 
> Ease of archiving, perhaps? A file system is just a specialized
> database - one can be as good as another.

I don't see how having it in a FM data field is easier to archive
than having it in the file system. Can you explain? 

> Regardless, what is your cut-off for moving data outside the
> database? A 4GB limit basically means there is no practical limit.
> That is the point. 

It depends on how accessible that data is.

It will always be accessible in the file system.

In a proprietary database format, the file will require the use of
the database engine to retrieve. In certain circumstances, it may
not be available. 

I'm surprised that you haven't mentioned the issue of full-text
indexing. That was the only reason I could conceive of for a 4GB
field size, for storing huge amounts of data that can then be
indexed. Does FM has full-text indexing? Access/Jet certainly
doesn't. I've never really needed it, but if you're storing files in
the field, having the capability would get around one of the main
problems with not having it available in the file system. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:05:19 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10do9srd78qqde8@corp.supernews.com: 

> There is a post on ZDNet by someone who specializes in Oracle and
> SQL apps, but has grown to really like FileMaker for some of his
> apps.  It's sort of on topic with this thread.  At:
> 
> http://techupdate.zdnet.com/techupdate/stories/main/tools_for_the_r
> est_of_us.html 

Actually, that article raises an issue that's been mostely absent
from this comparison of FM and Access, and it's an issue where FM
seems to me to be light years ahead of Access -- web enabling apps. 

With Access, there really isn't anything there at all. Yes, there
are DAPs (and the older technology which I've forgotten), but those
aren't really usable, as both require client-side widget
installations and one particular browser, the bloody awful IE. 

Have any of you used the IWP features?

Does it really work to simply convert an existing LAN/desktop/server
app into a web-based app? 

How is it accomplished? Entirely without any client-side
installation at all? Or is it Java or something? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:10:05 PM
"Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
news:10doh1j8gqf6r2b@corp.supernews.com: 

> "NB" <nickbose@softhome.net> wrote in message
> news:5240fc76.0406241903.51a3813c@posting.google.com...
> 
><SNIP>
> 
>> qryCelkoBOM :
>> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
>> FROM P, P AS P_1, P AS P_2
>> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between
>> [P].[lft]+1 And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And
>> (P_2.lft) Between [P_1].[lft] And [P_1].[rgt]))
>> GROUP BY P_2.MemberName;
>>
>> How would we do this in FM?
> 
> I am not familiar with SQL, therefore I have no idea what this
> means.  If you posted the results of your query, I might be able
> to respond. 

There's one of the problems of not supporting SQL right there -- you
can't communicate easily with the whole field of people out there
who are using all the other databases that speak SQL natively. 

This was one of the things that struck me about the discussion I
described of the poor FM end-user who couldn't figure out how to
copy data from a calculated field into a real field -- they were
speaking in terms that didn't translate well, and left the rest of
us who had no FM experience unable to help. 

On the other hand, when someone in the same forum posts a SQL
problem, there are literally dozens of people equipped to provide a
solution, and often there's several different ways in SQL to get the
appropriate result. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:15:38 PM
42 <42@nospam.com> wrote in news:5EMCc.847648$Pk3.803086@pd7tw1no:

> David W. Fenton wrote:

>> Aha. So it's not just transparent. Someone else said that
>> migrating from Jet to MSDE/SQL Server was not transparent and
>> implied that there were no such redesign issues with FM. So what
>> you're saying is that the situation with FM is pretty much the
>> same: if you design for the migration on the front end, it can be
>> pretty painless. 
> 
> There are two categories of things that can go wrong. Things
> pertaining to the migration between two engines, and things
> specific to multi-user solutions.

And you're suggesting that because with FM it's the same issue, only
the multi-user issues are relevant in FM. That makes sense. 

> A single user FM solution going to multiuser FM needs to address
> the various extra things that can go wrong in multiuser systems.
> 
> The transition from JET to MSDE is more complicated. Not only do
> you have to deal with the 'multiuser issues', but you have to deal
> with a whole other category of issues with respect to differences
> between the JET and MSDE engines.

Data types and security. What else?

Those can easily be planned for.

> With FM with a well designed solution all you literally have to do
> is put the files on a server. JET->MSDE no matter how well thought
> out, will always be more painful than that.

But not by much, if you plan for it.

Of course, it would be very nice if Jet data types could be migrated
completely transparently to SQL Server. 

But I really do consider that fairly minor in comparison to the
issue of how data retrieval is done in the application. The
multi-user and client/server issues are far, far more complex than
simple data type and security settings. 


-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:20:21 PM
42 <42@nospam.com> wrote in news:FJMCc.883141$oR5.792331@pd7tw3no:

> Now, in the real world, most access setups use a client side
> deployment, and most fm setups use a server side deployment. That
> means, in the real world, fm admins spend less time/effort/money
> dealing with deployment. 
> 
> Is that a fair way to put it?

The amount of time the Access developers spend is pretty trivial.

It really is.

Indeed, it can be zero, if using Tony Toews updater utility. Well,
not zero -- you have to set up and test the update script, but once
in place, new front ends are pushed out to the user completely
transparently. 

So, while it's a difference, it's relatively trivial in its
practical importance. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:23:51 PM
This is only my opinion, of course.  But small things that are so easy in
Access become a challenge in FM.   The structure of programming is hell.

I just tried to do the equivalent of an 'After_Update' event of a field, to
pop up a message if the value 'NONE' was entered.   I went NUT.



"Howard Schlossberg" <howard@antispahm.fmprosolutions.com> wrote in message
news:40DB931A.5070502@antispahm.fmprosolutions.com...
> Saintor wrote:
>
> > The worst thing - and it is still the same in FM7 - is the scriptmaker.
> > This is really a child's toy.and un-professional.
>
> This is what I don't understand.  What makes it unprofessional?  The
> fact that you can't use a text editor to change a script?
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Howard Schlossberg              (818) 883-2846
> FM Pro Solutions       Los Angeles, California
> Associate Member, FileMaker Solutions Alliance


0
Saintor
6/25/2004 4:24:26 PM
You went nuts because you didn't know how to do something?  Do you think 
I'd find it any easier to open Access and attempt the same?  Doubtful. 
Oracle's certainly not unprofessional; could you open Oracle and do the 
same thing right now?

Saintor wrote:
> This is only my opinion, of course.  But small things that are so easy in
> Access become a challenge in FM.   The structure of programming is hell.
> 
> I just tried to do the equivalent of an 'After_Update' event of a field, to
> pop up a message if the value 'NONE' was entered.   I went NUT.
> 
> 
> 
> "Howard Schlossberg" <howard@antispahm.fmprosolutions.com> wrote in message
> news:40DB931A.5070502@antispahm.fmprosolutions.com...
> 
>>Saintor wrote:
>>
>>
>>>The worst thing - and it is still the same in FM7 - is the scriptmaker.
>>>This is really a child's toy.and un-professional.
>>
>>This is what I don't understand.  What makes it unprofessional?  The
>>fact that you can't use a text editor to change a script?
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Howard Schlossberg              (818) 883-2846
>>FM Pro Solutions       Los Angeles, California
>>Associate Member, FileMaker Solutions Alliance
> 
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 4:29:32 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dn7ai78kuh075@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Of course, what you say about intermingling seems to contradict
>> what some of the other FM friends have said -- they say it's easy
>> to separate them. I assumed this was with the server version,
>> though, where you have a file of data that the server deals with
>> and then your layouts file that connects to the server data. 
>> 
>> Is that close?
> 
> Close, but not exactly.  As for the intermingling, a FileMaker
> developer COULD completely separate things, but they would lose
> the ability to lose calculation type fields under some
> circumstances.  You don't have calc fields in Access . . .

Of course you have calculated fields. They just aren't defined in
the table definition, but in queries (or SQL defined at runtime). 

> . . . -- which is
> fine -- but that means that you need to set calc'd variables by
> script.  One could do the same thing in FileMaker, but it adds a
> layer of complexity in the scripting that just usually is
> necessary.  So we opt to keep the calc fields and compromise on
> complete and total separation. 

This is where I see issues. Calculated fields in table definitions
are fine for end users, but they can lead to problems in terms of
maintenance. Access has these lookup fields (dropdown lists) that
can be stored in the table definitions, and they can lead to endless
problems, not so much because of the implementation, but because of
the things they hide and the dependencies they introduce. 

However, you can also define these dropdown lists in stored queries
where they don't interfere with the base table's design (though the
dependencies on other tables can still lead to problems, just less
widespread, since only the objects based on that saved query have a
problem, whereas with the dropdowns defined in the table definition,
all objects using that table can inherit the problems). 

> As for system configuration, I think you might misunderstand
> something. 
>   If a developer wanted to, he/she could have an interface file
>   that sat 
> on a client machine.  But I don't see a lot of advantage with
> that.  In fact, the disadvantage is that if you needed to make any
> changes, you'd have to send each client a new copy of the
> interface file. 

As with Access, that is much less of a problem than it may seem to
be. Many people start out Access development sharing a front end and
run into various kinds of problems (I understand that FM doesn't
have those problems) and are resistant to putting a front end on
every client workstation, since it seems hopelessly difficult to
deal with. Once they've done it, though, they realize it is no big
deal at all (it's just a file copy operation), and I spend little or
no time on this issue in any given week. 

> In FileMaker, all database files are generally hosted by FileMaker
> Server (or on the new FM Server Advanced, for web, XSLT, ODBC and
> JDBC services).  A client can connect to the server and see
> whatever files are being hosted and that are designated for that
> client to see.  A solution's main file might act as strictly an
> interface file, working in conjunction with other interface and/or
> logic and/or data files that are hidden on the server.  Keep in
> mind that all of these files have the same potential to
> incorporate multiple data tables, scripting, layouts (forms),
> reports -- it just depends on how the developer chooses to 
> structure it. 

This sounds like an excellent design.

> Changes to any of the elements in each served file, including data
> structure, can be made on the live file (if desired) and users
> will immediately benefit from those changes.  Or, if preferred, a
> copy of the solution could be opened by a client off-line for
> development.  The database behaves (basically) the same regardless
> of whether it is hosted by the client or by the server.  The
> primary concern when moving a solution to Server is that it will
> now be a shared, multi-user solution and any potential
> record-locking issues need to be taken into consideration. 
> Generally, FileMaker handles the record-locking and releasing
> automatically without any additional scripting.  But one could 
> inadvertantly lock a related record without realizing it if the 
> developer didn't consider the way he was setting it up.

Lynn said that FM used record-level locking. In what circumstances
would another record be inadvertently locked? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 4:30:21 PM
"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns95137CBFE9F8Adfentonbwaynetinvali@24.168.128.90...
> "Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
> news:10doh1j8gqf6r2b@corp.supernews.com:
>
> > "NB" <nickbose@softhome.net> wrote in message
> > news:5240fc76.0406241903.51a3813c@posting.google.com...
> >
> ><SNIP>
> >
> >> qryCelkoBOM :
> >> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
> >> FROM P, P AS P_1, P AS P_2
> >> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between
> >> [P].[lft]+1 And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And
> >> (P_2.lft) Between [P_1].[lft] And [P_1].[rgt]))
> >> GROUP BY P_2.MemberName;
> >>
> >> How would we do this in FM?
> >
> > I am not familiar with SQL, therefore I have no idea what this
> > means.  If you posted the results of your query, I might be able
> > to respond.
>
> There's one of the problems of not supporting SQL right there -- you
> can't communicate easily with the whole field of people out there
> who are using all the other databases that speak SQL natively.
>

Not understanding SQL is normally not a problem in a FileMaker discussion.
And, I didn't think responding to the question "How would we do this in FM?"
would require understanding SQL because the solution wouldn't involve using
SQL (if it did, there would be no point to the question).  I assumed
(wrongly) that I would have data (which I got) and result (which I didn't)
to work with.  How it would be done in an application that is unfamiliar to
me didn't help me.  I suppose I could have run out and bought "SQL for
Dummies" and then answered the question, but thought it would be easier to
ask for what I needed here.

> This was one of the things that struck me about the discussion I
> described of the poor FM end-user who couldn't figure out how to
> copy data from a calculated field into a real field -- they were
> speaking in terms that didn't translate well, and left the rest of
> us who had no FM experience unable to help.
>

Sounds like they were in the wrong forum.

> On the other hand, when someone in the same forum posts a SQL
> problem, there are literally dozens of people equipped to provide a
> solution, and often there's several different ways in SQL to get the
> appropriate result.
>

Seems to validate my previous point.


0
Glenn
6/25/2004 5:00:52 PM
David W. Fenton wrote:

> "Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
> news:10doh1j8gqf6r2b@corp.supernews.com: 

> This was one of the things that struck me about the discussion I
> described of the poor FM end-user who couldn't figure out how to
> copy data from a calculated field into a real field -- they were
> speaking in terms that didn't translate well, and left the rest of
> us who had no FM experience unable to help. 

Seems like the problem is that she was asking the wrong people for help. 
I see your point, but it's not valid due to there being FM help readily 
available. (this newsgroup, for example).


> On the other hand, when someone in the same forum posts a SQL
> problem, there are literally dozens of people equipped to provide a
> solution, and often there's several different ways in SQL to get the
> appropriate result. 
> 

What if her problem was with Access development and there were only 
Oracle developers around? She would still have a problem, but it's not 
the fault of Access. You wouldn't start a campaign saying Access should 
work exactly like Oracle, would you?
0
Kevin
6/25/2004 5:01:10 PM
David W. Fenton wrote:

> Does it really work to simply convert an existing LAN/desktop/server
> app into a web-based app? 

Yes, there's no conversion necessary. You just click on "Web Sharing". 
However, in previous versions Instant Web Publishing (IWP) provided only 
basic browsing, searching, and listing features. You ended up doing 
custom web pages using an FM web language called CDML.

In version 7, FM beefed up IWP a lot but I haven't played with it too 
much yet. It does seem to be pretty capable though. FM Server Advanced 
when released this summer, will provide XML/XSLT based web publishing as 
well as IWP.

> 
> How is it accomplished? Entirely without any client-side
> installation at all? Or is it Java or something? 
> 

Yes, no client installation - all through a web browser. It's all 
HTML/XML/XSLT based.
0
Kevin
6/25/2004 5:05:49 PM
"42" <42@nospam.com> wrote in message
news:FqLCc.891642$Ig.650726@pd7tw2no...
>
> The last thing *I* want to do is run an installer complete with with an
> 'add remove program icon' everytime you send me an MSOffice document.
>
> But if you want to create an installer for a single file that really
> just needs to be dragged wherever the user wants to run it from ... then
> ok... sure. Personally I'd rather see it in the my documents folder
> where its more likely to be backed up, then in the program folder. (This
> assuming a single user solution where the 'data' is stored locally -- in
> a multiuser setup there is no reason to put anything other than
> filemaker on the local hard drive in the vast majority of cases.)

Multi-user, or not, it is not a big deal.

You also see a differnt aprpoach here. You don't really want to think of the
applciaton some file that belongs in my documents, but as a applicatin that
gets deplyed to a workstation.

> > question was in regards to support, and deployment. If people as a
general
> > rule use the FM installer in place of what is a simple file copy, then I
am
> > surprised
> >
>
> Actually in most cases the user doesn't do *anything* at all. The file
> gets dropped on the server, and the user opens filemaker, selects open
> remote, selects the database from the list of available databases, and
> that's it.

Yes, that is the difference here. I talking bout deploying applications
here. Users run Word, users run Excel, uses run My job costing system, Users
run my Quotes system. Users run my Invoicing system (this are all systems I
wrote for ONE company with ms-access. They don't launch ms-access, and then
go hum...now..what am I to do here? Further, not all workstations need all
of the applications. Further, when running an application, you don't want
users browsing some big set of files, and "hope" they pick the right one.

You run the IE explore, you run word, you run my job cost system.

When that application runs, you don't see, nor get the ms-access interface.
FM has always been weak in this regards. A common complaint was that you
can't really hide the interface, and built a standard looking windows
application. Users should NOT have to know about opening the file and
selecting it from some list. In fact, for a good application a user should
NOT have to have a knowledge of how to use FM.

I mean, sure, a lot access applications expose the query builder, and things
like all the reports in the reports tab. However, good applications as a
rule will NOT expose the ms-access UI to users, and hide these things..

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/25/2004 7:02:47 PM
Albert D. Kallal wrote:


> You run the IE explore, you run word, you run my job cost system.
> 
> When that application runs, you don't see, nor get the ms-access interface.
> FM has always been weak in this regards.

FM has always been different in this regard. I wouldn't call it a 
weakness, you can hide the FM interface, if you want, and most good apps 
do. The only thing you can't really hide is that you are running 
Filemaker. But FM hosts the files, interprets them, and presents them, 
the paradigm is different. FM applications are fm documents... you would 
no more expect to open an fm document without seeing the fm splash 
screen than you would expect to open a word document without seeing a 
word splash screen... or even a Windows Application without first 
seening the Windows Splash Screen.

> A common complaint was that you
> can't really hide the interface, and built a standard looking windows
> application. Users should NOT have to know about opening the file and
> selecting it from some list.

They don't /have/ to. You can put a shortcut on their desktop or on the 
file server that launches your application. (ie launches FM, and opens 
the appropriate server hosted files)

> In fact, for a good application a user should
> NOT have to have a knowledge of how to use FM.

This is a misconception. For a good application you don't. Most users of 
most FM applications have no idea how to do anything "in filemaker".

> I mean, sure, a lot access applications expose the query builder, and things
> like all the reports in the reports tab. However, good applications as a
> rule will NOT expose the ms-access UI to users, and hide these things..

Good FM apps do not allow average users to have access to script maker 
or the layout designer or have the avility to define fields and 
relationships.
0
42
6/25/2004 7:19:24 PM
"Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
news:10domi7td5hced1@corp.supernews.com: 

> "David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
> news:Xns95137CBFE9F8Adfentonbwaynetinvali@24.168.128.90...

>> This was one of the things that struck me about the discussion I
>> described of the poor FM end-user who couldn't figure out how to
>> copy data from a calculated field into a real field -- they were
>> speaking in terms that didn't translate well, and left the rest
>> of us who had no FM experience unable to help.
> 
> Sounds like they were in the wrong forum.
> 
>> On the other hand, when someone in the same forum posts a SQL
>> problem, there are literally dozens of people equipped to provide
>> a solution, and often there's several different ways in SQL to
>> get the appropriate result.
> 
> Seems to validate my previous point.

It's a forum where a lot of professionals with a great deal of
knowledge congregate. Very few of them know anything about
Filemaker. Very few of them know anything about Access. But I can
get great answers to SQL problems in that forum. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 8:15:53 PM
Kevin Hayes <me@here.com> wrote in
news:cbhlk1$a9t$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> "Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
>> news:10doh1j8gqf6r2b@corp.supernews.com: 
> 
>> This was one of the things that struck me about the discussion I
>> described of the poor FM end-user who couldn't figure out how to
>> copy data from a calculated field into a real field -- they were
>> speaking in terms that didn't translate well, and left the rest
>> of us who had no FM experience unable to help. 
> 
> Seems like the problem is that she was asking the wrong people for
> help. I see your point, but it's not valid due to there being FM
> help readily available. (this newsgroup, for example).

But it's more limited when compared to the fact that all SQL
documentation on the web is possibly able to help solve problems on
any SQL-enabled database platform. 

>> On the other hand, when someone in the same forum posts a SQL
>> problem, there are literally dozens of people equipped to provide
>> a solution, and often there's several different ways in SQL to
>> get the appropriate result. 
> 
> What if her problem was with Access development and there were
> only Oracle developers around? She would still have a problem, but
> it's not the fault of Access. You wouldn't start a campaign saying
> Access should work exactly like Oracle, would you?

They would have been able to give her the SQL to copy the data from
the calculated fields to the new fields. 

And that's my point -- SQL is (mostly) platform-agnostic. A simple
field update is supported identically in all SQL dialects. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 8:17:59 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dokndgqn4dq6e@corp.supernews.com: 

> You went nuts because you didn't know how to do something?  Do you
> think I'd find it any easier to open Access and attempt the same? 
> Doubtful. Oracle's certainly not unprofessional; could you open
> Oracle and do the same thing right now?

Oracle is not a front-end programming tool, so not relevant to the
problem space. 

What about AfterUpdate or BeforeUpdate events of fields:

1. in FM, can you check the value before the underlying data field
is updated and prompt the user if it's not valid? 

2. do you have events that allow you to format data input after the
input is accepted? 

The first one I just did today. I had a form where there is a unique
index on two main fields, and I didn't want the user to get the
underlying Jet error message for a unique index collision, since
it's too generic to be understandable by most users. So, I wrote a
small subroutine that tests the values entered into the two controls
bound to the two fields and then looks up to see if there's already
an entry for that unique combination. I then call that in the
BeforeUpdate of the two controls (nothing happens if both fields are
not filled in), which prompts the user that there is already an
existing record for that date and unit number, and prevents them
from navigating out of the control until they've resolved the
problem. 

Can that be done in FM?

The complex event model of Access is one of its great strengths, in
that you have a great deal of control over different parts of the
process of getting input from the user into your actual data tables. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 8:23:42 PM
42 <42@nospam.com> wrote:

>Just fire up Visual Studio and build the front end in .NET in VB/C#, and 
>free yourself from licensing access.

Or use the Access runtime and free yourself from licensing Access.

Tony
--
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
http://www.granite.ab.ca/accsmstr.htm
0
Tony
6/25/2004 8:24:30 PM
David W. Fenton wrote:

> But it's more limited when compared to the fact that all SQL
> documentation on the web is possibly able to help solve problems on
> any SQL-enabled database platform. 

All the FM documentation on the web is possibly able to help solve 
problems on any FM database.

>>What if her problem was with Access development and there were
>>only Oracle developers around? She would still have a problem, but
>>it's not the fault of Access. You wouldn't start a campaign saying
>>Access should work exactly like Oracle, would you?
> 
> They would have been able to give her the SQL to copy the data from
> the calculated fields to the new fields. 

I said database development, not performing a query. Let me reword it: 
what if she was having a problem getting layout controls to work 
correctly and there were only Oracle developers around? You wouldn't 
start a campaign saying Access should work exactly like Oracle, would 
you? Of course not. You would tell her to ask Access developers for help.

> And that's my point -- SQL is (mostly) platform-agnostic. A simple
> field update is supported identically in all SQL dialects. 

That's nice. With SQL the help is there when you need it. With FM, the 
help is there when you need it. She just went to the wrong place for 
help. That was my point. There is enough of a critical mass of FM help 
available that it doesn't matter what is more popular.
0
Kevin
6/25/2004 8:35:09 PM
David W. Fenton wrote:

> 1. in FM, can you check the value before the underlying data field
> is updated and prompt the user if it's not valid? 

Yes.

> 2. do you have events that allow you to format data input after the
> input is accepted? 

Via a plugin, yes.

Field validation can be based on a value, inclusion in lists, any 
calculation, etc. It's quite powerful, but the ability to run a script 
is the only thing the you need the third party plug in for. The script 
would then format the data.

> The first one I just did today. I had a form where there is a unique
> index on two main fields, and I didn't want the user to get the
> underlying Jet error message for a unique index collision, since
> it's too generic to be understandable by most users. So, I wrote a
> small subroutine that tests the values entered into the two controls
> bound to the two fields and then looks up to see if there's already
> an entry for that unique combination. I then call that in the
> BeforeUpdate of the two controls (nothing happens if both fields are
> not filled in), which prompts the user that there is already an
> existing record for that date and unit number, and prevents them
> from navigating out of the control until they've resolved the
> problem. 
> 
> Can that be done in FM?

Yes. Under field validation check the "Unique" checkbox. You can also 
check "Display custom error message" and enter the message, or let 
FileMaker display the standard "Field not unique" message. No 
subroutines are required.

> The complex event model of Access is one of its great strengths, in
> that you have a great deal of control over different parts of the
> process of getting input from the user into your actual data tables. 

A lot of what people would do with that event model is built into FM. 
I'm sure you can come up with some examples that couldn't be done - but 
a lot of that can be done in FM through third party plug-ins.
0
Kevin
6/25/2004 8:45:26 PM
Kevin Hayes wrote:


> A lot of what people would do with that event model is built into FM. 
> I'm sure you can come up with some examples that couldn't be done - but 
> a lot of that can be done in FM through third party plug-ins.

And much of that is 'using it because its *there* that way' not 'because 
you *need* it that way'.

Access and Filemaker are not 2 paths to an identical end result like C# 
and VB.NET. They lead to 2 separate end results that each meet the 
problem slightly differently.

Compare programming in .NET and Java. They do things a little 
differently, their libraries of objects all behave a little differently. 
Making Java behave exactly like .NET can be exceedingly difficult... but 
making .NET behave exactly like Java is similiarly difficult. Access and 
FM solutions are similiar in that regard.

If the problem is 'validating a field' in Access you would solve it one 
way, in filemaker you might solve it another way. Getting access to do 
it the 'filemaker way' might be impossible, getting filemaker to do it 
the 'access way' starts needing plugins and gets unnecessarily cumbersome.
0
42
6/25/2004 9:40:23 PM
Kevin Hayes <me@here.com> wrote in
news:cbi258$o2u$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> But it's more limited when compared to the fact that all SQL
>> documentation on the web is possibly able to help solve problems
>> on any SQL-enabled database platform. 
> 
> All the FM documentation on the web is possibly able to help solve
> problems on any FM database.

There's far more SQL documentation and shelves of books on the
subject of SQL. 

If FM had SQL support, you wouldn't have to use it, just as you
don't actually have to know SQL to use Access (though every single
data-bound object in Access is actually populated from SQL). 

>>>What if her problem was with Access development and there were
>>>only Oracle developers around? She would still have a problem,
>>>but it's not the fault of Access. You wouldn't start a campaign
>>>saying Access should work exactly like Oracle, would you?
>> 
>> They would have been able to give her the SQL to copy the data
>> from the calculated fields to the new fields. 
> 
> I said database development, not performing a query. Let me reword
> it: what if she was having a problem getting layout controls to
> work correctly and there were only Oracle developers around? . . .

But that wasn't the problem she was having, that is, the problem I
discussed in my example. The whole reason the lack of SQL in FM
struck me as a lack was precisely because of the triviality of
copying the data with SQL. 

> . . . You
> wouldn't start a campaign saying Access should work exactly like
> Oracle, would you? Of course not. You would tell her to ask Access
> developers for help. 

I'm not saying FM should work exactly like any other product. I'm
only suggesting that if it supported SQL a lot more people might
find it easy to adapt to and then there might be a lot more people
using it. 

>> And that's my point -- SQL is (mostly) platform-agnostic. A
>> simple field update is supported identically in all SQL dialects.
> 
> That's nice. With SQL the help is there when you need it. With FM,
> the help is there when you need it. She just went to the wrong
> place for help. That was my point. There is enough of a critical
> mass of FM help available that it doesn't matter what is more
> popular. 

If she'd had SQL at her disposal, the problem would have been
solved. 

As it was, she didn't get a workable solution.

The conclusion seems obvious to me.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 9:51:15 PM
Kevin Hayes <me@here.com> wrote in
news:cbi2og$olt$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> 1. in FM, can you check the value before the underlying data
>> field is updated and prompt the user if it's not valid? 
> 
> Yes.
> 
>> 2. do you have events that allow you to format data input after
>> the input is accepted? 
> 
> Via a plugin, yes.
> 
> Field validation can be based on a value, inclusion in lists, any 
> calculation, etc. It's quite powerful, but the ability to run a
> script is the only thing the you need the third party plug in for.
> The script would then format the data.

Is the script defined in the field definition or in form layouts?

>> The first one I just did today. I had a form where there is a
>> unique index on two main fields, and I didn't want the user to
>> get the underlying Jet error message for a unique index
>> collision, since it's too generic to be understandable by most
>> users. So, I wrote a small subroutine that tests the values
>> entered into the two controls bound to the two fields and then
>> looks up to see if there's already an entry for that unique
>> combination. I then call that in the BeforeUpdate of the two
>> controls (nothing happens if both fields are not filled in),
>> which prompts the user that there is already an existing record
>> for that date and unit number, and prevents them from navigating
>> out of the control until they've resolved the problem. 
>> 
>> Can that be done in FM?
> 
> Yes. Under field validation check the "Unique" checkbox. You can
> also check "Display custom error message" and enter the message,
> or let FileMaker display the standard "Field not unique" message.
> No subroutines are required.

Er, sorry, but that's not the same thing. It would require putting
the validation message in two places. It would also require being
able to evaluate a lookup or run a script in the validation rule. 

Access/Jet provides validation rules and validation messages, but I
hardly use them, since they are not sufficiently controllable in the
UI. 

>> The complex event model of Access is one of its great strengths,
>> in that you have a great deal of control over different parts of
>> the process of getting input from the user into your actual data
>> tables. 
> 
> A lot of what people would do with that event model is built into
> FM. I'm sure you can come up with some examples that couldn't be
> done - but a lot of that can be done in FM through third party
> plug-ins. 

All of Access's events have default behaviors. The point is that
those events are exposed to allow the definition of custom behaviors
without requiring any 3rd-party products. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 9:54:00 PM
"42" <42@nospam.com> wrote in message
news:0V_Cc.898821$Ig.300482@pd7tw2no...

> you would
> no more expect to open an fm document without seeing the fm splash
> screen than you would expect to open a word document without seeing a
> word splash screen... or even a Windows Application without first
> seening the Windows Splash Screen.

No, I don't want to see the FM splash..I want to see MY splash screen, and
have my logo appear in the task bar?

What about when I build my application using ms-access? I don't want a
windows splash, or a ms-access splash screen? Who wants that?

I want my own splash screen (which you can have with ms-access). I want my
own icon to appear in the windows task bar.

(what happens when you have 3 FM applications running at the same time? How
do you know which one is which?.  Can you run them as 3 separate
applications at the same time?

I also want my own ICON to appear in the task bar, and you can also setup
the little icon in the corner of each window also.

> Good FM apps do not allow average users to have access to script maker
> or the layout designer or have the avility to define fields and
> relationships.

No, but you can't obviously create a windows application that follows
standard UI either..then..can you?

Take a read of the following as to why you would do this, and note the
sample ms-access screen shots:

http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

-- 
Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.attcanada.net/~kallal.msn


0
Albert
6/25/2004 9:54:09 PM
42 <42@nospam.com> wrote in news:bZ0Dc.889848$oR5.782445@pd7tw3no:

> If the problem is 'validating a field' in Access you would solve
> it one way, in filemaker you might solve it another way. Getting
> access to do it the 'filemaker way' might be impossible, getting
> filemaker to do it the 'access way' starts needing plugins and
> gets unnecessarily cumbersome. 

But you really don't understand. The BeforeUpdate and AfterUpdate
events are events of the control that is bound to the data field,
not events connected to an underlying data field and defined in a
table definition. The BeforeUpdate and AfterUpdate events occur even
on fields that aren't bound to an underlying data field. 

Do the textbox controls in FM have a rich event model, or are you
limited only to the characteristics of the fields bound to them? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/25/2004 9:56:12 PM
Albert D. Kallal wrote:

> "42" <42@nospam.com> wrote in message
> news:0V_Cc.898821$Ig.300482@pd7tw2no...
> 
> 
>>you would
>>no more expect to open an fm document without seeing the fm splash
>>screen than you would expect to open a word document without seeing a
>>word splash screen... or even a Windows Application without first
>>seening the Windows Splash Screen.
> 
> 
> No, I don't want to see the FM splash..I want to see MY splash screen, and
> have my logo appear in the task bar?
> 
> What about when I build my application using ms-access? I don't want a
> windows splash, or a ms-access splash screen? Who wants that?
> 
> I want my own splash screen (which you can have with ms-access).

You can splash your own image too with FM, when you open your 
application, after opening FM.

> I want my
> own icon to appear in the windows task bar.

> (what happens when you have 3 FM applications running at the same time? How
> do you know which one is which?.  Can you run them as 3 separate
> applications at the same time?
> 
> I also want my own ICON to appear in the task bar, and you can also setup
> the little icon in the corner of each window also.

/shrug

I'm disappointed to see this discussion has degenerated to a my platform 
is better because i get to put my icon here and here and there.

Personally that's pretty low on my list of things to look for in an a 
platform. I guess if you want your icon in the task bar, and the project 
could have been done in filemaker for 1/3rd the time and 1/3rd cost... 
then well... its your time & money.

>>Good FM apps do not allow average users to have access to script maker
>>or the layout designer or have the avility to define fields and
>>relationships.
> 
> 
> No, but you can't obviously create a windows application that follows
> standard UI either..then..can you?

I fail to see what preventing the user from accessing the layout 
designer (etc) has to do with developing applications with good UI.

> Take a read of the following as to why you would do this, and note the
> sample ms-access screen shots:
> 
> http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm
> 
I have taken accredited courses at universities on human-computer 
interaction. I assure you Filemaker is more than up to the task of 
allowing applications to be developed where zero training is required.

What I found most amusing though is that, as a windows developer you 
have chosen to adopt the windows standards without a blink. As a 
cross-platform developer its worth pointing out that many things that 
windows users take for granted are not remotely intuitive or easy. Just 
because Microsoft has conditioned its users to expect certain things, 
that doesn't make those things terribly bright.

That said, I _do_ advocate following the guidelines for Windows Logo 
certification when developing on the windows platform.
0
42
6/25/2004 10:39:18 PM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:bZ0Dc.889848$oR5.782445@pd7tw3no:
> 
> 
>>If the problem is 'validating a field' in Access you would solve
>>it one way, in filemaker you might solve it another way. Getting
>>access to do it the 'filemaker way' might be impossible, getting
>>filemaker to do it the 'access way' starts needing plugins and
>>gets unnecessarily cumbersome. 
> 
> 
> But you really don't understand.

I understand perfectly.

> The BeforeUpdate and AfterUpdate
> events are events of the control that is bound to the data field,
> not events connected to an underlying data field and defined in a
> table definition. The BeforeUpdate and AfterUpdate events occur even
> on fields that aren't bound to an underlying data field. 
> 
> Do the textbox controls in FM have a rich event model, or are you
> limited only to the characteristics of the fields bound to them? 

FMs event model is weaker than Access'. Much of the textbox's behaviour 
is defined by the underlying data field. This isn't nearly the 
limitation you might think, though. You can simply define a 'utility 
table' with fields with the characteristics you want, and then by script 
push the values to the 'real underlying data field' once the validation 
or whatever has been met.

This is the typical way of handling all sorts of issues in filemaker. 
Where the user must either change all 3 fields, or none of them. The 
normal behviour, is as soon as the user exits the field (and the 
validation passes) the database is updated. If you want the user to 
enter a screen change 10 vields, validate them via a script, and then 
commit them, that's how its done.

FM doesn't have 'local variables' like access... everthing is a field. 
For what its worth not having variables *is* a significant weakness of FM.


0
42
6/25/2004 10:48:29 PM
>> The worst thing - and it is still the same in FM7 - is the scriptmaker.
>> This is really a child's toy.and un-professional.
> 
> That "child's toy" has helped me earn thousands of dollars. By 
> definition, that would make it professional.

Same here... more even

-- 
----------------------------------------
Quantum Illusions: http://quantum.2ya.com
FORT Freeware: http://freeware.quantum.2ya.com
Pegasus Mail Support Site: http://pegasus.quantum.2ya.com
DATA Solutions: http://datasolutions.quantum.2ya.com

If you truly want to contact me click the link
http://quantum.2ya.com/email.htm

The future is our past and our past is our future.
0
Bebop
6/25/2004 11:38:36 PM
David W. Fenton wrote:
  > Lynn said that FM used record-level locking. In what circumstances
> would another record be inadvertently locked? 
>
With FileMaker 7, it would primarily be when you enter a portal row 
(which is a related record), in which case that foreign record would be 
locked AND the current (local) record would be locked.  This does make a 
lot of sense that it would be this way.  Clicking into a field does not 
lock the record.  It only locks as soon as the first modification is 
made to any data in the record.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 11:48:34 PM
David W. Fenton wrote:

> But it's more limited when compared to the fact that all SQL
> documentation on the web is possibly able to help solve problems on
> any SQL-enabled database platform. 

But if I was Joe Schmo, Office Worker, would I have any idea of how to 
use the SQL statement that all these very knowledgable and professional 
people are giving me?  Where do I enter it?  What will I do with the 
results?  Is there a form I use with that?  Would someone on the SQL 
newsgroup be able to tell me specifically what to do in Access?

These questions are rhetorical.  In my mind, it still all comes down to 
having an intuitive interface that non-developers can use to do what 
they want.  And for FileMaker developers, there are plenty of great 
resources and on-line discussion groups to get answers to problems.

I was at one point in my career very good with SQL.  Once I started 
using FileMaker, I found I didn't really need it unless I needed to pull 
data from Sybase or another app.  It was handy to have, but it really 
hasn't been an issue for me in my FileMaker world.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/25/2004 11:59:57 PM
David W. Fenton wrote:

> Oracle is not a front-end programming tool, so not relevant to the
> problem space. 

That's not my point.  Point is that if you know the tool, then it is
simple.  If you don't, then it's not.

> What about AfterUpdate or BeforeUpdate events of fields:
> 
> 1. in FM, can you check the value before the underlying data field
> is updated and prompt the user if it's not valid? 

Yes.  Of course there is field validation that doesn't let you enter
invalid data.

> 2. do you have events that allow you to format data input after the
> input is accepted? 

Yes.  FM doesn't call it an event, but yes: just set up an auto-enter
calculation that formats it the way you want.  Whenever the field value
is changed, it will automatically reformat itself per the developer's specs.

> The first one I just did today. I had a form where there is a unique
> index on two main fields, and I didn't want the user to get the
> underlying Jet error message for a unique index collision, since
> it's too generic to be understandable by most users. So, I wrote a
> small subroutine that tests the values entered into the two controls
> bound to the two fields and then looks up to see if there's already
> an entry for that unique combination. I then call that in the
> BeforeUpdate of the two controls (nothing happens if both fields are
> not filled in), which prompts the user that there is already an
> existing record for that date and unit number, and prevents them
> from navigating out of the control until they've resolved the
> problem. 
> 
> Can that be done in FM?

You can have a customized error message for each field, that FM pops up 
on validation errors.  By adding a free plug-in to your solution, you 
can use the validation to trigger a script upon a failed validation to 
do whatever you want.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance

0
Howard
6/26/2004 12:19:25 AM
David W. Fenton wrote:

> Is the script defined in the field definition or in form layouts?

As mentioned in my last post, there is no need to run a script for this. 
  A simple auto-enter calc can be defined in field defintions.  Field 
definitions are accessible at any time by those with the proper 
credentials, even if 50 other people are in the database.


> All of Access's events have default behaviors. The point is that
> those events are exposed to allow the definition of custom behaviors
> without requiring any 3rd-party products. 

Running a script upon field exit can be done with a free plug-in 
provided with FileMaker Developer.  It is not a third-party plugin.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 12:26:52 AM
Albert D. Kallal wrote:

> No, I don't want to see the FM splash..I want to see MY splash screen, and
> have my logo appear in the task bar?

When you run a solution through the FileMaker Developer Tool, you can 
designate your own graphic to use as a splash upon opening (or is it 
upon closing?)


>>Good FM apps do not allow average users to have access to script maker
>>or the layout designer or have the avility to define fields and
>>relationships.
> 
> No, but you can't obviously create a windows application that follows
> standard UI either..then..can you?
> 
> Take a read of the following as to why you would do this, and note the
> sample ms-access screen shots:
> 
> http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

I browsed through that link and everything on there seems perfectly 
do-able in FileMaker.  You can allow users to edit some scripts and not 
others, or allow them only to add scripts or layouts, but not modify. 
Allow them to change account settings through a user interface without 
giving them full access.  No problem.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 12:32:14 AM
FileMaker is not object-oriented (yet).  There are no events tied to any 
layout objects.  But this is easily accomplished by adding a script that 
gets triggered (via plugin) upon exiting a field, or via a button 
overlayed on a field upon entering it.

David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:bZ0Dc.889848$oR5.782445@pd7tw3no:
> 
> 
>>If the problem is 'validating a field' in Access you would solve
>>it one way, in filemaker you might solve it another way. Getting
>>access to do it the 'filemaker way' might be impossible, getting
>>filemaker to do it the 'access way' starts needing plugins and
>>gets unnecessarily cumbersome. 
> 
> 
> But you really don't understand. The BeforeUpdate and AfterUpdate
> events are events of the control that is bound to the data field,
> not events connected to an underlying data field and defined in a
> table definition. The BeforeUpdate and AfterUpdate events occur even
> on fields that aren't bound to an underlying data field. 
> 
> Do the textbox controls in FM have a rich event model, or are you
> limited only to the characteristics of the fields bound to them? 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 12:34:29 AM
> You went nuts because you didn't know how to do something?  

**And** because the help files and support groups were zero
assistance.

How do you replace the After_Update/Before_Update events of a control
in Filemaker?  I found nothing.  Maybe I am wrong.  But events
management in Filemaker seems nowhere close to Access.
0
saintor1
6/26/2004 12:41:57 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> 
> Please explain how one would use a 4GB field.

one day, a man said :
who needs a date after year 2000 ?

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:52 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> Why would those who promote FM downplay its support of SQL?

they think that SQL is an old fashionnable and nowadays unuseful langage
of the 70's
old fashionnable dbm'adms use it as COBOL programmers where doing in the
80's.

with querys and script of FMP or 4D, you can do what you need, more
easily and quickly than with SQL ; that's the point.
SQL isn't a necessity for FMP users, it's a tolerance for all those poor
dinos working with old tools. SQL is a pity. And thnaks to god, we don't
have a FMP tool speaking SQL !!! and no more crank in my car.

a bit of evolution, please.

who use COBOL, now ?

COBOL was very powerfull, too.
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:52 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> FM can do VB?

only on Windows PCs...
with a mac, you can use AppleScript, but that needs a completely
different development

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:52 AM
NB <nickbose@softhome.net> wrote:

> qryCelkoBOM :
> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
> FROM P, P AS P_1, P AS P_2
> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between [P].[lft]+1
> And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And (P_2.lft) Between
> [P_1].[lft] And [P_1].[rgt]))
> GROUP BY P_2.MemberName;

sorry, i don't speak chineese.
explain what are the datas, the links beetween them and what you want to
obtain in clear words.

that's the way FMP works.

in fact, I see someone responded, but this is to illustrate the narrow
minded way of your propositions.

the point to understand is that FMP use 3 completely separated steps for
searching datas, sorting them, and finally viewing related fields ;
that's a big advantage on SQL, and that's why SQL isn't the good tool to
work with FMP. Nor with any good DB...
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:53 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> They just aren't defined in
> the table definition, but in queries (or SQL defined at runtime). 

example : calculated field X  = field A + Field B
do you mean that the field X is calculated during the data input of
(A,B) or the viewing process ?

- what in the case of changes in field A (wich in fact is a linked field
of another DB via a value of field C)
- if you decide that now X = A + B/2 : what about the 472 reports or
scripts using the value of X
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:53 AM
Albert D. Kallal <PleaseNOOOsPAMMkallal@msn.com> wrote:

> You just
> create your tables, and draw lines for your relations,

this is the way 4D works since 1986...
Thanks to Laurent Ribardiere !
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:43:54 AM
Saintor wrote:

>>You went nuts because you didn't know how to do something?  

> **And** because the help files and support groups were zero
> assistance.

You obviously didn't try very hard.  This particular newsgroup is more 
of a beginner and intermediate level group, although there are a number 
of advanced and experts monitoring and contributing to it.  There are at 
least four other major on-line discussion groups that cater to all 
levels through expert.  Plus, there are developer or user groups in many 
major cities around the world.  This morning, I met with 50 other 
professional FileMaker developers in the Los Angeles area (we have close 
to 150 in our group).  Plus, the TechInfo database on FileMaker's own 
website can be quite helpful in helping to narrow down issues.  And 
there's always the manual (which you apparently haven't read) and a 
handful of books that are available on Amazon and at most decent bookstores.

> How do you replace the After_Update/Before_Update events of a control
> in Filemaker?  I found nothing.  Maybe I am wrong.  But events
> management in Filemaker seems nowhere close to Access.

FileMaker is not an object-oriented database.  There are no event 
controls built into layout objects.  But as I've already noted, there 
are simple enough ways to do what you want.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 1:52:27 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> 
> I don't see how having it in a FM data field is easier to archive
> than having it in the file system. Can you explain?

Imagine an image db where only references are stored. Now burn it onto a
CD. Oops, all your paths are now invalid. No images display.

Or you have an overactive IT department with a big budget. They're
always moving files from server to server during upgrades or replacing
servers entirely and dinking with your paths. Display of referenced
images depends on the path remaining constant, as they are not relative.
In this case, having files internal to FM is much better, particularly
as they are now accessible through export.  
> 

> In a proprietary database format, the file will require the use of
> the database engine to retrieve. In certain circumstances, it may
> not be available.

FM 7 now permits the export of container field data in the format in
which it was inserted. In FM 6 it is possible with a plugin. 
> 
> I'm surprised that you haven't mentioned the issue of full-text
> indexing. That was the only reason I could conceive of for a 4GB
> field size, for storing huge amounts of data that can then be
> indexed. Does FM has full-text indexing? Access/Jet certainly
> doesn't. I've never really needed it, but if you're storing files in
> the field, having the capability would get around one of the main
> problems with not having it available in the file system.

Yes, FM does full-text indexing. I don't know if anyone has done testing
with large numbers of 4G records (I think I'd want a really FAST
network) but logically this should work well because with the new FM
Server 7 most of the work of the search is done on the server.

I am not sure one can search, say, a Word document imported. It would be
a bit much to expect that the same search could look inside Word, Excel,
other FM files and/or graphics. The full-text search probably only
applies to actual naked text copied or imported into FM.

Lynn Allen
www.semiotics.com


FM 7 Tip of the Week: External authentication can permit IT departments
to create and manage user accounts which log into FM. Security becomes
the responsiblity of IT, not FM. 
0
lynn
6/26/2004 3:07:42 AM
"manet" <pmanet@invivo.edu> wrote

 > - what in the case of changes in field A
 > (wich in fact is a linked field of another
 > DB via a value of field C) - if you decide
 > that now X = A + B/2 : what about the
 > 472 reports or scripts using the value of X

Storing a field that can be calculated from other fields in the same record
is redundant, and it is a violation of good relational database design
principles, according to all the authoritative references on that subject
that I have read.

I'm not sure, exactly, what you mean by "(wich in fact is a linked field of
another DB via a value of field C)". In Access, and in the server databases
with which I have worked, you can link _tables_ in other databases, but not
_fields_ within those tables. I have, briefly, worked with some PC
"databases" (but not really relational DBs) that had calculated field
capability (in re: which, see the following).

It's also something I learned long before people called any data store a
"database", in mainframe file systems -- have only one authoritative source
for any value. Sooner or later, if you don't follow that guideline, you will
be faced with a situation where the two, or more, authoritative sources
don't agree and then you have to determine which is the _most_
authoritative.

I've worked on some pretty big systems, PC, minicomputer, and mainframe and
can't remember a single one with "472" reports, or anywhere near that. I
can't even imagine an application where I would use the same value,
calculated from other values in the same record, in more than a handful. I
can calculate it either as a "calculated field" in a Query (which Query
could be used as the RecordSource for multiple Reports or Forms) or as a
"calculated control" on the Report itself.

   Larry Linson
   Microsoft Access MVP



0
Larry
6/26/2004 5:11:27 AM
Larry Linson wrote:

> "manet" <pmanet@invivo.edu> wrote
> 
>  > - what in the case of changes in field A
>  > (wich in fact is a linked field of another
>  > DB via a value of field C) - if you decide
>  > that now X = A + B/2 : what about the
>  > 472 reports or scripts using the value of X
> 
> Storing a field that can be calculated from other fields in the same record
> is redundant, and it is a violation of good relational database design
> principles, according to all the authoritative references on that subject
> that I have read.

But storing a calculation field which is *defined* as a calculation of 
A+B is not redundant in the least, hell it doesn't even need to be 
"stored", and can be calculated on the fly whenever its needed, an 
exists essentially as a convenient alias to the calculation. Although if 
you do store it you can index it... and there is some value to that too.

Everybody knows that 'good relational design' is a balancing act with 
performance, in any system.
0
42
6/26/2004 6:05:04 AM
Howard Schlossberg wrote:
> 
> FileMaker is not an object-oriented database.  There are no event 
> controls built into layout objects.  But as I've already noted, there 
> are simple enough ways to do what you want.
> 
Yup. The problem is that he asked for how to do something Access does 
.... If he'd just said what he actually wanted to get done and didn't 
restrict himself to thinking only in terms of how access does things 
he'd get a lot farther.
0
42
6/26/2004 6:10:13 AM
Actually, ever since FMPro 6 SQL 92 is supported in all detail, that is
necessary for ODBC connectivity to databases like DB2 and Oracle.
You will find in the help all info regarding how to create SQL queries and
deploy them on external databases to retrieve data into the FM Pro database

regards


On 25-06-2004 23:51, in article
Xns9513B6EC6AD1Ddfentonbwaynetinvali@24.168.128.74, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbi258$o2u$1@zcars0v6.ca.nortel.com:
> 
>> David W. Fenton wrote:
>> 
>>> But it's more limited when compared to the fact that all SQL
>>> documentation on the web is possibly able to help solve problems
>>> on any SQL-enabled database platform.
>> 
>> All the FM documentation on the web is possibly able to help solve
>> problems on any FM database.
> 
> There's far more SQL documentation and shelves of books on the
> subject of SQL. 
> 
> If FM had SQL support, you wouldn't have to use it, just as you
> don't actually have to know SQL to use Access (though every single
> data-bound object in Access is actually populated from SQL).
> 
>>>> What if her problem was with Access development and there were
>>>> only Oracle developers around? She would still have a problem,
>>>> but it's not the fault of Access. You wouldn't start a campaign
>>>> saying Access should work exactly like Oracle, would you?
>>> 
>>> They would have been able to give her the SQL to copy the data
>>> from the calculated fields to the new fields.
>> 
>> I said database development, not performing a query. Let me reword
>> it: what if she was having a problem getting layout controls to
>> work correctly and there were only Oracle developers around? . . .
> 
> But that wasn't the problem she was having, that is, the problem I
> discussed in my example. The whole reason the lack of SQL in FM
> struck me as a lack was precisely because of the triviality of
> copying the data with SQL.
> 
>> . . . You
>> wouldn't start a campaign saying Access should work exactly like
>> Oracle, would you? Of course not. You would tell her to ask Access
>> developers for help.
> 
> I'm not saying FM should work exactly like any other product. I'm
> only suggesting that if it supported SQL a lot more people might
> find it easy to adapt to and then there might be a lot more people
> using it. 
> 
>>> And that's my point -- SQL is (mostly) platform-agnostic. A
>>> simple field update is supported identically in all SQL dialects.
>> 
>> That's nice. With SQL the help is there when you need it. With FM,
>> the help is there when you need it. She just went to the wrong
>> place for help. That was my point. There is enough of a critical
>> mass of FM help available that it doesn't matter what is more
>> popular. 
> 
> If she'd had SQL at her disposal, the problem would have been
> solved. 
> 
> As it was, she didn't get a workable solution.
> 
> The conclusion seems obvious to me.

0
Rob
6/26/2004 11:57:20 AM
In article <1Z1Dc.899284$Ig.856178@pd7tw2no>, 42 <42@nospam.com> wrote:

>FM doesn't have 'local variables' like access... everthing is a field. 
>For what its worth not having variables *is* a significant weakness of FM.

But then, global fields can act as variables quite handily.  In my own FM
evolution, I've gradually moved away from using globals for most other
reasons, but have increasingly relied on them to act as variables.

Steve Brown
0
eyebrown
6/26/2004 12:05:58 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> But you really don't understand.

YOU don't understand that fmp IS NOT Access

what you describe is controling user's entry.

Yes, it can be done, and in most of the cases very more easily that in
Acces, as I hope you can understand in Howard's responses (that's to
say, without one line of coding).

If you want very specific and unusual feature, it can be done in
different ways, with a script controlling temporary fields before
pushing them in the good ones (this is my preference) or using plugins.
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:51:37 PM
Larry  Linson <bouncer@localhost.not> wrote:

> Storing a field that can be calculated from other fields in the same record
> is redundant, and it is a violation of good relational database design
> principles

yes, it has been said in the 70's, when RAM was in big assemblies of
tores and datas were stored on magnetic tapes... and old dinosauruses
continue telling that to their poor students... but hat remains an
assertion needing demonstration in the actual setting of YOUR actual DB.

in the real life, having automatically calculated fields before looking
them is a guaranty of speed when needing them for retrieving or sorting.
But yes, it takes RAM, disk place, CPU, and needs to be used only when
really needed.

It's right that beginners uses them to frequently. With little DB, it's
not a problem ; it becomes when the little DB become a professional one.

What is great with FMP, is that you can, then, on the fly, change the
kind of field from "calcultated" to "number" or "date" or "text",
keeping the datas in it, and without having to rewrite all the scripts,
sorting, etc... relative to it.

Surely, you'll have to write a script doing the calc for populating him
when needed...

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:51:38 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> > All the FM documentation on the web is possibly able to help solve
> > problems on any FM database.
> 
> There's far more SQL documentation and shelves of books on the
> subject of SQL. 


what is "fare more" that "all that is needed" ?

it's "to much".

and to much isn't a good thing, because it implies frequently bad and
false things.

-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:51:38 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

>  I'm
> only suggesting that if it supported SQL a lot more people might
> find it easy to adapt to and then there might be a lot more people
> using it. 

it takes a couple of hours tu understand how to replace all that
bullshit SQL with simple FMP functions.

If they had the use of SQL in FMP, SQL devs would continue to use it.
It's not a good idea.
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:51:39 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> If she'd had SQL at her disposal, the problem would have been
> solved. 

as Howard said, I don't think so.
this person can't ever understand that for solving his problem, she had
to look at an FMP competent ressource.
I doubt she can apply any valuable SQL statement. And more, I'm afraid
she would try !

On another point, I don't understand you, who knows this newsgroup.
Why didn't you give this adress to this poor lady ? That was the good
way for help.
-- 
Philippe Manet
pmanet@invivo.edu
0
pmanet
6/26/2004 12:51:39 PM
> >>You went nuts because you didn't know how to do something?  
>  
> > **And** because the help files and support groups were zero
> > assistance.
> 
> You obviously didn't try very hard.  

I looked in the 5+ yrs archives.  Nothing.


> > How do you replace the After_Update/Before_Update events of a control
> > in Filemaker?  I found nothing.  Maybe I am wrong.  But events
> > management in Filemaker seems nowhere close to Access.
> 
> FileMaker is not an object-oriented database.  There are no event 
> controls built into layout objects.  But as I've already noted, there 
> are simple enough ways to do what you want.

No offense meant, but I doubt it.  Certainly not 'simple'.  We are NOT
talking about field validation here.  The events management is now
something I could not live without.
0
saintor1
6/26/2004 1:07:49 PM
Saintor wrote:

>>FileMaker is not an object-oriented database.  There are no event 
>>controls built into layout objects.  But as I've already noted, there 
>>are simple enough ways to do what you want.
> 
> No offense meant, but I doubt it.  Certainly not 'simple'.  We are NOT
> talking about field validation here.  The events management is now
> something I could not live without.

I'm not taling about field validation either.  As far as I'm concerned, 
field validation is handled fine by FileMaker's own handling.  But you 
can run event scripts using a free plug-in, triggered by changing a 
field, changing records, clicking into a field, exiting a record...what 
am I missing?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 5:15:44 PM
eyebrown@mindspring.com wrote:

> In article <1Z1Dc.899284$Ig.856178@pd7tw2no>, 42 <42@nospam.com> wrote:
> 
> 
>>FM doesn't have 'local variables' like access... everthing is a field. 
>>For what its worth not having variables *is* a significant weakness of FM.
> 
> 
> But then, global fields can act as variables quite handily.  In my own FM
> evolution, I've gradually moved away from using globals for most other
> reasons, but have increasingly relied on them to act as variables.

Yes, globals can act as variables, and in FM they are the only option, 
but as *any* programmer will tell you local variables are *much* easier 
to work with in many situations, and they make the code more logical and 
easier to maintain.

After all, if I need a counter in a particular script why does the 
entire application need to know about it?
0
42
6/26/2004 8:15:27 PM
42 <42@nospam.com> wrote:

> >>FM doesn't have 'local variables' like access... everthing is a field.
> >>For what its worth not having variables *is* a significant weakness of FM.
> > 
> > 
> > But then, global fields can act as variables quite handily.  In my own FM
> > evolution, I've gradually moved away from using globals for most other
> > reasons, but have increasingly relied on them to act as variables.
> 
> Yes, globals can act as variables, and in FM they are the only option,
> but as *any* programmer will tell you local variables are *much* easier
> to work with in many situations, and they make the code more logical and
> easier to maintain.

Before FM 7, this was true. Now there is a "Let" functions which DOES
introduce local variables. It'll take a bit for us to get the hang of
this, but along with the new "Evaluate" function, it's an extremely
powerful new (to FM) feature.

Lynn ALlen
www.semiotics.com


FM 7 Tip of the Week: External authentication can permit IT departments
to create and manage user accounts which log into FM. Security becomes
the responsiblity of IT, not FM. 
0
lynn
6/26/2004 8:57:09 PM
pmanet@invivo.edu (manet) wrote in news:20040626145138650803@[10.0.0.1]:

> and to much isn't a good thing, because it implies frequently bad and
> false things.

How many posts have you made to this thread? Some might think it is TOO many.


-- 
Lyle
(for e-mail refer to http://ffdba.com/)
--
use iso dates
http://www.w3.org/QA/Tips/iso-date
0
Lyle
6/26/2004 9:53:22 PM
Lynn allen wrote:
> 42 <42@nospam.com> wrote:
> 
> 
>>>>FM doesn't have 'local variables' like access... everthing is a field.
>>>>For what its worth not having variables *is* a significant weakness of FM.
>>>
>>>
>>>But then, global fields can act as variables quite handily.  In my own FM
>>>evolution, I've gradually moved away from using globals for most other
>>>reasons, but have increasingly relied on them to act as variables.
>>
>>Yes, globals can act as variables, and in FM they are the only option,
>>but as *any* programmer will tell you local variables are *much* easier
>>to work with in many situations, and they make the code more logical and
>>easier to maintain.
> 
> 
> Before FM 7, this was true. Now there is a "Let" functions which DOES
> introduce local variables. It'll take a bit for us to get the hang of
> this, but along with the new "Evaluate" function, it's an extremely
> powerful new (to FM) feature.
> 
> Lynn ALlen
> www.semiotics.com
> 
> 
> FM 7 Tip of the Week: External authentication can permit IT departments
> to create and manage user accounts which log into FM. Security becomes
> the responsiblity of IT, not FM. 

Perhaps I'm mistaken, but my understanding of the let command, is that 
it only allows you create a name for a complicated calculation.

e.g. if I have a field with the text
myField="hello my birthdate is 1/4/02!"

then you can use the let command to create an alias 'variable' for the 
forumula:

birthdate = left(rightwords(myfield,1),length(rightwords(myfield,1)-1)

and just use 'birthdate' every time you needed it, instead of using the 
long messy expression.

I also thought the let expressions were simple substitutions... e.g. if 
I changed 'myfield' to 'hello my birthdate is 1/5/05' the let expression 
would evaluate differently. This makes them unsuitable as 'variables'; 
they are really merely just 'named expressions'

I could be off, i have just started working with 7, as I had to wait for 
server to release before it made much sense for me, but that's what I 
gleaned from reading the manual/help file.
0
42
6/26/2004 10:01:07 PM
Lynn allen wrote:
> Before FM 7, this was true. Now there is a "Let" functions which DOES
> introduce local variables. It'll take a bit for us to get the hang of
> this, but along with the new "Evaluate" function, it's an extremely
> powerful new (to FM) feature.

And don't forget the new ability to pass parameters between scripts 
without using global fields.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 10:02:29 PM
Howard Schlossberg wrote:

> Lynn allen wrote:
> 
>> Before FM 7, this was true. Now there is a "Let" functions which DOES
>> introduce local variables. It'll take a bit for us to get the hang of
>> this, but along with the new "Evaluate" function, it's an extremely
>> powerful new (to FM) feature.
> 
> 
> And don't forget the new ability to pass parameters between scripts 
> without using global fields.
> 

I missed that new box on the perform script dialog box. Thanks for the 
heads up, that's a godsend!!
0
42
6/26/2004 10:08:27 PM
42 <42@nospam.com> wrote in news:qQ1Dc.899273$Ig.603891@pd7tw2no:

> I'm disappointed to see this discussion has degenerated to a my
> platform is better because i get to put my icon here and here and
> there. 
> 
> Personally that's pretty low on my list of things to look for in
> an a platform. I guess if you want your icon in the task bar, and
> the project could have been done in filemaker for 1/3rd the time
> and 1/3rd cost... then well... its your time & money.

I strongly doubt that there is much difference in the amount of time
it takes an experienced FM developer to finish an application
compared to an experienced Access developer. I can't see anything
that is different enough about the two platforms in terms of RAD
capabilities that would make one significantly slower than the
other. The only things that would make development take longer seem
to resolve in Access's favor (mostly in regard to deeper programming
capabilities and a much richer event model). 

But even then the difference is not going to be comparable to the
difference between building an app in Access and building it in VB
-- indeed, my bet is that it would be trivial in comparison. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:22:06 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dph0gqpdbf4f4@corp.supernews.com: 

> Albert D. Kallal wrote:
> 
>> No, I don't want to see the FM splash..I want to see MY splash
>> screen, and have my logo appear in the task bar?
> 
> When you run a solution through the FileMaker Developer Tool, you
> can designate your own graphic to use as a splash upon opening (or
> is it upon closing?)
> 
>>>Good FM apps do not allow average users to have access to script
>>>maker or the layout designer or have the avility to define fields
>>>and relationships.
>> 
>> No, but you can't obviously create a windows application that
>> follows standard UI either..then..can you?
>> 
>> Take a read of the following as to why you would do this, and
>> note the sample ms-access screen shots:
>> 
>> http://www.attcanada.net/
~kallal.msn/Articles/UseAbility/UserFrien
>> dly.htm 
> 
> I browsed through that link and everything on there seems
> perfectly do-able in FileMaker.  You can allow users to edit some
> scripts and not others, or allow them only to add scripts or
> layouts, but not modify. . . .

Er, what?

Albert's example has nothing to do with editing "scripts and
layout." It's about permission to edit *data*. 

> . . . Allow them to change account settings
> through a user interface without giving them full access.  No
> problem. 

Albert's point was not that it is not doable, but that the issue of
not having separate icons and of not being able to have your own
splash screen without also having a generic splash screen means that
your program does not behave in the expected manner in comparison to
other programs. While users can certainly learn to ignore these
issues or work around them, Albert's point is that Access capability
to do these things means *they don't have to*. 

It's a small issue, yes, but it's a difference, nonetheless.

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:27:48 PM
Rob Tito <cassiope@wanadoo.nl> wrote in
news:BD033140.5F039%cassiope@wanadoo.nl: 

> Actually, ever since FMPro 6 SQL 92 is supported in all detail,
> that is necessary for ODBC connectivity to databases like DB2 and
> Oracle. You will find in the help all info regarding how to create
> SQL queries and deploy them on external databases to retrieve data
> into the FM Pro database 

I've gone through this several times and repeatedly get the same
answer back, and it's an answer that seems to fundamentally
misunderstand my question. 

It seems clear from what people have said that you can use SQL for
data retrieval into FM from ODBC data sources that suppport SQL. 

BUT THIS IS NOT MY QUESTION.

My question is about FM's native methods for retrieving data, not
about how to retrieve data from non-native data sources. 

1. Can SQL be used to populate data-bearing controls in FM when you
are *not* using an ODBC data source (i.e., native FM data)? 

2. Is SQL supported by FM as a native part of data retrieval, with
query optimization and SQL validity checking, or is FM completely
ignorant of the internals of any SQL statements sent to an external
data source? 

The answer I'm expecting from everything I've read is that SQL is
simply not supported by FM except at the trivial level of being able
to pass it to non-native data sources to retrieve data. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:31:38 PM
pmanet@invivo.edu (manet) wrote in
news:20040626145139650861@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> If she'd had SQL at her disposal, the problem would have been
>> solved. 
> 
> as Howard said, I don't think so.
> this person can't ever understand that for solving his problem,
> she had to look at an FMP competent ressource.
> I doubt she can apply any valuable SQL statement. And more, I'm
> afraid she would try !

You're simply wrong. Given her table and field names, anyone with
SQL knowledge could have written a SQL statement that she could have
cut and pasted into her database and executed to update the column. 

That is, if her database supported SQL.

I don't think you really do understand SQL, or you'd understand that
it is trivial for someone to write a valid SQL statement, given the
table and field names. 

And she wouldn't have been required to do anything but paste it into
her database for execution. 

> On another point, I don't understand you, who knows this
> newsgroup. Why didn't you give this adress to this poor lady ?
> That was the good way for help.

I didn't know this newsgroup existed then. In case you haven't
noticed, this thread is cross-posted. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:34:07 PM
pmanet@invivo.edu (manet) wrote in
news:20040626145139650833@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>>  I'm
>> only suggesting that if it supported SQL a lot more people might
>> find it easy to adapt to and then there might be a lot more
>> people using it. 
> 
> it takes a couple of hours tu understand how to replace all that
> bullshit SQL with simple FMP functions.

If FM supported SQL, that's a couple of hours that one could be
working on a better UI, or on making more attractive layouts, or on
any number of other real improvements to an applcation. 

> If they had the use of SQL in FMP, SQL devs would continue to use
> it. It's not a good idea.

Why is it not a good idea?

Would it be a good idea for the Filemaker newsgroup to require posts
be made in Sanskrit, and that anyone wanting to get any benefit out
of your newsgroup should first learn Sanskrit? 

I'm not suggestion that current functionality in FM would be altered
by having SQL support, just that having SQL support built in would
make FM more attractive to larger number of users, because it would
then be using an industry-standard interface language for retrieving
data. 

If you can't see that, you can't see it.

But it's blazingly obvious to anyone from the outside.

Lacking SQL doesn't make FM unusable for those not experienced with
it already, but it certainly makes it a lot less likely that they
will attempt to learn it. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:37:29 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dpgmm58o7lc59@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Is the script defined in the field definition or in form layouts?
> 
> As mentioned in my last post, there is no need to run a script for
> this. 
>   A simple auto-enter calc can be defined in field defintions. 
>   Field 
> definitions are accessible at any time by those with the proper 
> credentials, even if 50 other people are in the database.

Is this "field definition" in the table definition or in the screen
layout? 

In Access, you have the choice of using validation rules in either
the field definition in the table definition or in a control on a
form. You also have the choice of writing code hooked into any
number of events of the control on the form that you're using to
edit the data (though all these events already have their own
default behaviors). 

Does FM offer choices as to where to validate the data, or is it
definable only in the field definition of the table? 

>> All of Access's events have default behaviors. The point is that
>> those events are exposed to allow the definition of custom
>> behaviors without requiring any 3rd-party products. 
> 
> Running a script upon field exit can be done with a free plug-in 
> provided with FileMaker Developer.  It is not a third-party
> plugin. 

OK, that wasn't clear to me from the context.

But it still doesn't answer my fundamental question, as it's not
clear to me if FM terminology differentiates the term "field" from
the term "control" in a data editing layout (a control is the widget
used to display and edit the field in the underlying data table). 

Events, for instance, don't really belong in data tables, seems to
me, since data tables are not UI components. 

Secondly, if only the table definition can define these validation
rules, how do you handle cases where the rules are different based
on what values have been chosen in other fields for a particular
record? In Access, you define that in your form. Can you do the same
in FM, or are you limited to defining validation rules within the
table? 

If the latter is true, then it would be an insurmountable problem
when the validation rules have to be different for different
contexts in which a table is used. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:43:02 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dph4o6g5ekqb2@corp.supernews.com: 

> FileMaker is not object-oriented (yet).  There are no events tied
> to any layout objects.  But this is easily accomplished by adding
> a script that gets triggered (via plugin) upon exiting a field, or
> via a button overlayed on a field upon entering it.

Well, a field departure is still an event, and a lot can be
accomplished in it. The problem, though, is controlling when the
underlying table is updated. If it's already updated by the time the
departure event occurs, then you can run into problems if your needs
in a particular layout are different from the generic validation
rules in the table definition. 

My example in another thread was where I needed two fields to be
unique. My table has a unique compound key on those two fields, so
it's impossible to add duplicate records. But the default Jet error
message for this is very user-unfriendly (perhaps FM's default error
messages are more user-friendly, or perhaps you can define a custom
error message for index violations), so I want to intercept the edit
*before* it gets written to the data table. In Access, I do this in
the BeforeUpdate event. It sounds like it simply wouldn't be
possible in FM, unless the actual updating of the underlying data
field doesn't happen until *after* the field departure is complete. 

Can the exit event of your FM field be cancelled?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:49:25 PM
pmanet@invivo.edu (manet) wrote in
news:20040626145137650735@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> But you really don't understand.
> 
> YOU don't understand that fmp IS NOT Access
> 
> what you describe is controling user's entry.
> 
> Yes, it can be done, and in most of the cases very more easily
> that in Acces, as I hope you can understand in Howard's responses
> (that's to say, without one line of coding).
> 
> If you want very specific and unusual feature, it can be done in
> different ways, with a script controlling temporary fields before
> pushing them in the good ones (this is my preference) or using
> plugins. 

What I'm asking for is not "very specific and unusual."

It's basic data entry validation.

It can also be done with very little code in Access, and often
without writing any. But some very common circumstances make the
ability to distinguish the sequence of events that happen when a
user edits data essential. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:51:00 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dpeekql2n8ld3@corp.supernews.com: 

> David W. Fenton wrote:
>  > Lynn said that FM used record-level locking. In what
>  > circumstances 
>> would another record be inadvertently locked? 
>>
> With FileMaker 7, it would primarily be when you enter a portal
> row (which is a related record), in which case that foreign record
> would be locked AND the current (local) record would be locked. 
> This does make a lot of sense that it would be this way.  Clicking
> into a field does not lock the record.  It only locks as soon as
> the first modification is made to any data in the record.

So, you're saying that for as long as the child record is locked,
the parent is also locked? 

That's kind of weird -- I'm having some difficulty coming up with a
plausible explanation for why this would be either necessary or
useful. Any suggestions? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:52:21 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dpf4019c2usac@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> But it's more limited when compared to the fact that all SQL
>> documentation on the web is possibly able to help solve problems
>> on any SQL-enabled database platform. 
> 
> But if I was Joe Schmo, Office Worker, would I have any idea of
> how to use the SQL statement that all these very knowledgable and
> professional people are giving me?  Where do I enter it?  What
> will I do with the results?  Is there a form I use with that? 
> Would someone on the SQL newsgroup be able to tell me specifically
> what to do in Access? 

No, you would certainly be on your own figuring out *how* to make
the SQL work. But, nonetheless, once you knew that, all the power of
SQL and all the resources available to explain it would be open to
you. 

> These questions are rhetorical.  In my mind, it still all comes
> down to having an intuitive interface that non-developers can use
> to do what they want.  And for FileMaker developers, there are
> plenty of great resources and on-line discussion groups to get
> answers to problems. 

Yet, this was a non-developer who couldn't figure out how to do
something really basic. I know her from her postings, and she isn't
by any means stupid. She was just having problems with the basics of
the FM UI in figuring out how to make it happen. And non of the half
dozen or so other FM sers who were advising her were successful in
helping her through her problems. 

> I was at one point in my career very good with SQL.  Once I
> started using FileMaker, I found I didn't really need it unless I
> needed to pull data from Sybase or another app.  It was handy to
> have, but it really hasn't been an issue for me in my FileMaker
> world. 

I'm not saying it should be.

I'm only arguing that if FM supported SQL it might be used a lot
more widely. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:55:00 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dpg8feukn2b09@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Oracle is not a front-end programming tool, so not relevant to
>> the problem space. 
> 
> That's not my point.  Point is that if you know the tool, then it
> is simple.  If you don't, then it's not.
> 
>> What about AfterUpdate or BeforeUpdate events of fields:
>> 
>> 1. in FM, can you check the value before the underlying data
>> field is updated and prompt the user if it's not valid? 
> 
> Yes.  Of course there is field validation that doesn't let you
> enter invalid data.

But when does it happen?

And is the control on the form independent from the field in the
underlying data table in terms of your control over events? 

>> 2. do you have events that allow you to format data input after
>> the input is accepted? 
> 
> Yes.  FM doesn't call it an event, but yes: just set up an
> auto-enter calculation that formats it the way you want.  Whenever
> the field value is changed, it will automatically reformat itself
> per the developer's specs. 

Is that in the table definition or on the screen layout?

>> The first one I just did today. I had a form where there is a
>> unique index on two main fields, and I didn't want the user to
>> get the underlying Jet error message for a unique index
>> collision, since it's too generic to be understandable by most
>> users. So, I wrote a small subroutine that tests the values
>> entered into the two controls bound to the two fields and then
>> looks up to see if there's already an entry for that unique
>> combination. I then call that in the BeforeUpdate of the two
>> controls (nothing happens if both fields are not filled in),
>> which prompts the user that there is already an existing record
>> for that date and unit number, and prevents them from navigating
>> out of the control until they've resolved the problem. 
>> 
>> Can that be done in FM?
> 
> You can have a customized error message for each field, that FM
> pops up on validation errors. . . .

For each field? Definied in the underlying table, or in the control
on the screen layout that is used to edit the underlying field? 

> . . . By adding a free plug-in to your
> solution, you can use the validation to trigger a script upon a
> failed validation to do whatever you want.

Can you control whether or not the pre-defined error message is
bypassed, or do you get it any time the validation fails? And can
you intercept the edit before it gets to the validation? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:57:29 PM
pmanet@invivo.edu (manet) wrote in
news:200406260243521746814@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> FM can do VB?
> 
> only on Windows PCs...
> with a mac, you can use AppleScript, but that needs a completely
> different development

That's an interesting capability.

FM has its own scripting language that works on both Mac and
Windows, right? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:58:06 PM
Lyle Fairfield <MissingAddress@Invalid.Com> wrote:

> 
> How many posts have you made to this thread?

for better clearness, 1 topic = 1 post

one only post with 40 lines and 5 topics is confusing

surely, this is better seen with a real newsreader, with a good
graphical representation of the threads
0
pmanet
6/26/2004 10:58:14 PM
pmanet@invivo.edu (manet) wrote in
news:200406260243531746834@[10.0.0.1]: 

> NB <nickbose@softhome.net> wrote:
> 
>> qryCelkoBOM :
>> SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
>> FROM P, P AS P_1, P AS P_2
>> WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between
>> [P].[lft]+1 And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And
>> (P_2.lft) Between [P_1].[lft] And [P_1].[rgt]))
>> GROUP BY P_2.MemberName;
> 
> sorry, i don't speak chineese.
> explain what are the datas, the links beetween them and what you
> want to obtain in clear words.
> 
> that's the way FMP works.
> 
> in fact, I see someone responded, but this is to illustrate the
> narrow minded way of your propositions.

Pardon me, but you are vastly in the minority of database developers
if you cannot understand the SQL statement above. 

> the point to understand is that FMP use 3 completely separated
> steps for searching datas, sorting them, and finally viewing
> related fields ; that's a big advantage on SQL, and that's why SQL
> isn't the good tool to work with FMP. Nor with any good DB...

This is meaningless.

Can FM do the important task accomplished in that SQL, which is very
common in a bill of materials, where you have recursive relations
within records within a single table? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 10:59:43 PM
pmanet@invivo.edu (manet) wrote in
news:200406260243531746869@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> They just aren't defined in
>> the table definition, but in queries (or SQL defined at runtime).
> 
> example : calculated field X  = field A + Field B
> do you mean that the field X is calculated during the data input
> of (A,B) or the viewing process ?

In your query, you'd have this SQL:

SELECT A, B, A + B As X
FROM MyTable

And the result would be a recordset with three columns:

  A     B     X
  1     2     3
  4     5     9

If fields A and B defaulted to a value of 0, it would always work,
and X would automatically update to reflect the calculated value any
time the values of fields A and B were changed. 

In other words, I expect that it works just about the same way as
calculated fields work in FM. You just don't store the calculated
values in the table definition, but instead in your recordsources
and rowsources of form, controls and reports. 

> - what in the case of changes in field A (wich in fact is a linked
> field of another DB via a value of field C)

You mean field A is a link to a different table?

Well, it depends on whether or not you've set up relationships that
cascade updates. 

If Table2 has field A and B, and Table1 has field A as it's parent
(as well as other fields), and the relationship is that the records
in Table2 are children of records in Table1, you can set up the
relationship to cascade updates in Table1's field A to the
corresponding field in Table2. 

However, in the real world, you hardly ever do this kind of cascade
update, because of problems that result from 

> - if you decide that now X = A + B/2 : what about the 472 reports
> or scripts using the value of X

If they are all based on a stored query that has the SQL I posted
above, you just altered that stored query to be: 

SELECT A, B, (A + B) / 2 As X
FROM MyTable

This means you have a layer in between your data table and the user
interface objects that present data from it and thus, an important
separation of presentation and underlying data. Calculated fields
are just presentation, and you don't want to do the calculations for
data that's not being presented. So, for a form where you don't need
the value of X, you'd use a recordsource that didn't do the
calculation, thus saving resources. 

It's a basic tenet of relational database theory that derived data
is never stored. I doubt that FM tables store the result of the
calculation, they just store the formula and calculate on the fly,
just like an Access query, or any dialect of SQL. It's not really a
violation of the basic principles of the theory to do that, but I do
think it can lead to bad practices by putting those calculations in
the table definition. And it can also be inefficient, though that
would depend entirely on how FM implements. 

In short, I don't see this difference between FM and Access as
having any real significance, to be honest. It's just different. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 11:09:23 PM
"Larry  Linson" <bouncer@localhost.not> wrote in
news:3A7Dc.682$x9.154@nwrddc02.gnilink.net: 

> "manet" <pmanet@invivo.edu> wrote
> 
> > - what in the case of changes in field A
> > (wich in fact is a linked field of another
> > DB via a value of field C) - if you decide
> > that now X = A + B/2 : what about the
> > 472 reports or scripts using the value of X
> 
> Storing a field that can be calculated from other fields in the
> same record is redundant, and it is a violation of good relational
> database design principles, according to all the authoritative
> references on that subject that I have read.

I suspect that FM's calculated fields do not store the derived
value, just the calculation. 

My bet is that, in Access terms, the FM calculated field is much
like lookup fields in Access table definitions -- derived data is
calculated on the fly from the formulat and displayed, but with no
actual duplication of data. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 11:11:06 PM
pmanet@invivo.edu (manet) wrote in
news:200406260243521746785@[10.0.0.1]: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> Why would those who promote FM downplay its support of SQL?
> 
> they think that SQL is an old fashionnable and nowadays unuseful
> langage of the 70's
> old fashionnable dbm'adms use it as COBOL programmers where doing
> in the 80's.

They may think that, but if they do, they are hopelessly mistaken.

> with querys and script of FMP or 4D, you can do what you need,
> more easily and quickly than with SQL ; . . .

*You* may be able to (and the question of whether Celko's bill of
materials nested set query can be replicated in FM remains open --
it's a serious issue and an important one), but if it could just be
a significant enough barrier to everyone else in the world who knows
SQL that they all reject FM as too insular. 

> . . . that's the point.
> SQL isn't a necessity for FMP users, it's a tolerance for all
> those poor dinos working with old tools. SQL is a pity. And thnaks
> to god, we don't have a FMP tool speaking SQL !!! and no more
> crank in my car. 

These kinds of statements are what make people like me who are
interested in FM but experienced with other tools just want to
dismiss all of you as a bunch of cranks who really don't know much. 

> a bit of evolution, please.
> 
> who use COBOL, now ?
> 
> COBOL was very powerfull, too.

COBOL has zilch to do with SQL.

And current varieties of SQL are based on SQL 92, which means it's
not much older than HTML, for instance. 

The other issue is that this kind of criticism of SQL shows that you
really don't even know what it is, a language designed to represent
and manipulate data according to set theory. There's a huge amount
of mathematical theory behind the design of SQL. 

And, so far as I know, the age of a mathematical tool does not
indicate its validity or usability -- the Pythagorean theorem is
just as true today as it was in ancient times. 

If all you have to say about SQL is name calling, then we really
have absolutely nothing to talk about. You don't seem to know enough
about it to be making any statements about its utility in any
circumstances. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 11:17:53 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10dplmu7euc0cf5@corp.supernews.com: 

> FileMaker is not an object-oriented database.  There are no event 
> controls built into layout objects.  But as I've already noted,
> there are simple enough ways to do what you want.

You seem not to know the meaning of the term "object-oriented."

Hint: Access is not object-oriented, either.

What you're looking for is "event-driven." And all GUI applications
are, by definition, event-driven. That FM would implement a GUI
development environment and not hook events to control that
environment seems to me to show a fundamental design problem. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 11:19:55 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gfyc8m.150efj17p13cwN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> I don't see how having it in a FM data field is easier to archive
>> than having it in the file system. Can you explain?
> 
> Imagine an image db where only references are stored. Now burn it
> onto a CD. Oops, all your paths are now invalid. No images
> display. 

You have 4GB CDs?

[]

>> In a proprietary database format, the file will require the use
>> of the database engine to retrieve. In certain circumstances, it
>> may not be available.
> 
> FM 7 now permits the export of container field data in the format
> in which it was inserted. In FM 6 it is possible with a plugin. 

It requires FM to export, no?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/26/2004 11:21:47 PM
I don't see it as an issue.  What do I care if my clients see that it's 
a FileMaker solution.  They've bought at least one seat of FileMaker. 
They know it's not some secret recipe I dreamed up.

David W. Fenton wrote:

> Albert's point was not that it is not doable, but that the issue of
> not having separate icons and of not being able to have your own
> splash screen without also having a generic splash screen means that
> your program does not behave in the expected manner in comparison to
> other programs. While users can certainly learn to ignore these
> issues or work around them, Albert's point is that Access capability
> to do these things means *they don't have to*. 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 11:28:23 PM
David W. Fenton wrote:

> My question is about FM's native methods for retrieving data, not
> about how to retrieve data from non-native data sources. 
> 
> 1. Can SQL be used to populate data-bearing controls in FM when you
> are *not* using an ODBC data source (i.e., native FM data)? 

No, but why would I care?  That's not how you do in FileMaker whatever 
it is that you do in Access.

> 2. Is SQL supported by FM as a native part of data retrieval, with
> query optimization and SQL validity checking, or is FM completely
> ignorant of the internals of any SQL statements sent to an external
> data source? 

There is a wizard in FileMaker to help compose SQL as a way of 
retreiving data from or writing data to external data sources.  It does 
check for grammar.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 11:31:50 PM
David W. Fenton wrote:

>>it takes a couple of hours tu understand how to replace all that
>>bullshit SQL with simple FMP functions.
> 
> If FM supported SQL, that's a couple of hours that one could be
> working on a better UI, or on making more attractive layouts, or on
> any number of other real improvements to an applcation. 
> 
David, I'm getting really bored now with this conversation.  FileMaker 
does not use SQL to access its internal data.  It has a different way of 
performing queries.  As I've said, I know SQL and any time savings would 
be minimal.  But it doesn't support SQL and, though it might be nice, it 
really doesn't matter nor do I feel that it slows me down in my 
development.  If you are going to insist on using SQL, then do not 
bother with Filemaker.  It's really as simple as that.  Are there other 
issues that you'd like to explore in comparing the two apps?  If not, 
then I think we're done.  Thanks for playing along.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 11:37:07 PM
David W. Fenton wrote:

 > Is this "field definition" in the table definition or in the screen
 > layout?

Field definitions are in the table definition.  If you want different
validation for the same field on different screens, then you can define
which layouts get which validation within the field's definition. Or 
else you can add an event via a plug-in to the field and use the 
triggered script to perform
your validation and do whatever you want.

I understand how Access does it and that Access is object-oriented. 
Access is somewhat more convenient in this way but, in my experience, 
only if you know VB.  If you know VB and you expext uninhibited 
object-level control, then you do not want to use FileMaker.  FileMaker 
does not do that.

 From a programming perspective -- and I've said this a couple times 
before in this thread -- Access is absolutely more powerful and more 
flexible.  That doesn't necessarily make it simpler.  But any tool is 
only simple in the hands of someone who knows how to use that tool.  I 
believe my end result solution is equal to yours in most respects, as 
far as the end user is concerned.  I also believe that my client can 
reach that end result much less expensively then they could using an 
Access developer.

> But it still doesn't answer my fundamental question, as it's not
> clear to me if FM terminology differentiates the term "field" from
> the term "control" in a data editing layout (a control is the widget
> used to display and edit the field in the underlying data table). 

A field is a column, defined as part of the table structure.  Fields can 
also be used as layout objects and can be displayed on each layout as 
either a standard text field, radio buttons, checkboxes, dropdown, etc.

> Events, for instance, don't really belong in data tables, seems to
> me, since data tables are not UI components. 

Events are controlled by scripts.  Scripts can be separated out, if 
you'd like, into a separate interface file.  Validation, on the other 
hand, does belong with the data tables; validation controls what is and 
is not allowed in a field -- how many characters should it be, should it 
be allowed if another field is not the correct value, etc.  If you want 
to consider this as business logic -- and I don't doubt that could be 
argued -- then you are free to create a script in the interface or 
business logic layers and design your layouts to run those scripts at 
the appropriate time, using different methods to run the scripts, 
depending on what you want to do.  This is all flexible, but that's the 
way validation and/or other types of scripts are handled.  If you prefer 
the way Access handles these things, then I would recommend sticking 
with Access; FileMaker would not be for you.


> Secondly, if only the table definition can define these validation
> rules, how do you handle cases where the rules are different based
> on what values have been chosen in other fields for a particular
> record? In Access, you define that in your form. Can you do the same
> in FM, or are you limited to defining validation rules within the
> table? 

You usually define it within your table, unless you want to script it to 
work only on a particular form.  Either way, you can compare as many 
fields as you want in a record (or with fields in a related record or 
series of records), you can allow it for some users and not others, on 
some layouts and not others -- whatever on earth you want to do.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 11:55:40 PM
David W. Fenton wrote:

  > My example in another thread was where I needed two fields to be
> unique. My table has a unique compound key on those two fields, so
> it's impossible to add duplicate records. But the default Jet error
> message for this is very user-unfriendly (perhaps FM's default error
> messages are more user-friendly, or perhaps you can define a custom
> error message for index violations), so I want to intercept the edit
> *before* it gets written to the data table. In Access, I do this in
> the BeforeUpdate event. It sounds like it simply wouldn't be
> possible in FM, unless the actual updating of the underlying data
> field doesn't happen until *after* the field departure is complete. 
> 
> Can the exit event of your FM field be cancelled?

Field data is not committed until you exit the record.  Before exiting 
the record, you always have the option to revert that record (and any 
related records that might have been touched from a particular layout). 
  On a per-layout basis, the developer also has the ability to require a 
user's 'OK' before committing the record.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/26/2004 11:59:09 PM
David W. Fenton wrote:

>>With FileMaker 7, it would primarily be when you enter a portal
>>row (which is a related record), in which case that foreign record
>>would be locked AND the current (local) record would be locked. 
>>This does make a lot of sense that it would be this way.  Clicking
>>into a field does not lock the record.  It only locks as soon as
>>the first modification is made to any data in the record.
> 
> 
> So, you're saying that for as long as the child record is locked,
> the parent is also locked? 
> 
> That's kind of weird -- I'm having some difficulty coming up with a
> plausible explanation for why this would be either necessary or
> useful. Any suggestions? 

If you are on a particular layout that represents the parent record, and 
you have a portal on that layout that represents a child record, and you 
make a change to any field, then the parent record is locked.  If you 
also edit one of the child fields, then that record is also locked. 
This gives you the opportunity to revert the parent record, which would 
also revert the child record.  It assumes that if you are editing on the 
parent's screen, then you intend on that screen's record being locked.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 12:02:17 AM
David W. Fenton wrote:

>>These questions are rhetorical.  In my mind, it still all comes
>>down to having an intuitive interface that non-developers can use
>>to do what they want.  And for FileMaker developers, there are
>>plenty of great resources and on-line discussion groups to get
>>answers to problems. 
> 
> Yet, this was a non-developer who couldn't figure out how to do
> something really basic. I know her from her postings, and she isn't
> by any means stupid. She was just having problems with the basics of
> the FM UI in figuring out how to make it happen. And non of the half
> dozen or so other FM sers who were advising her were successful in
> helping her through her problems. 

Well, now you know about this newsgroup, which is more geared toward end 
users and beginning to intermediate developers.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 12:03:54 AM
David W. Fenton wrote:

>>>2. do you have events that allow you to format data input after
>>>the input is accepted? 
>>
>>Yes.  FM doesn't call it an event, but yes: just set up an
>>auto-enter calculation that formats it the way you want.  Whenever
>>the field value is changed, it will automatically reformat itself
>>per the developer's specs. 
> 
> 
> Is that in the table definition or on the screen layout?

Table definition, which is where it should be.  The idea here (it sounds 
to me) is for consistancy of data across the board.  Table defintion is 
therefore where it belongs.  If you want to control it on a per-screen 
layout, then you can either define that in the table definition or in a 
per-layout script triggered by the free plug-in.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 12:06:40 AM
David W. Fenton wrote:

>>>qryCelkoBOM :
>>>SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
>>>FROM P, P AS P_1, P AS P_2
>>>WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between
>>>[P].[lft]+1 And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And
>>>(P_2.lft) Between [P_1].[lft] And [P_1].[rgt]))
>>>GROUP BY P_2.MemberName;

> Can FM do the important task accomplished in that SQL, which is very
> common in a bill of materials, where you have recursive relations
> within records within a single table? 
> 
Once again, yes.  Looks to me like a search across some relationships 
and a calc field, then sorted and summarized into a report layout.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 12:12:59 AM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> > as Howard said, I don't think so.
> > this person can't ever understand that for solving his problem,
> > she had to look at an FMP competent ressource.
> > I doubt she can apply any valuable SQL statement. And more, I'm
> > afraid she would try !
> 
> You're simply wrong. Given her table and field names, anyone with
> SQL knowledge could have written a SQL statement that she could have
> cut and pasted into her database and executed to update the column.

You're simply wrong. She was asking for  help with a Filemaker database,
and asking in the wrong place.  
> 
> That is, if her database supported SQL.
> 
> I don't think you really do understand SQL, or you'd understand that
> it is trivial for someone to write a valid SQL statement, given the
> table and field names.

It's also trivial for someone who knows how to write a script to parse
data out of a field into two others in FM. If she'd asked the correct
people, she'd have had her answer in as little time as if she'd asked a
SQL question in the forum she unfortunately chose. 
> 
> And she wouldn't have been required to do anything but paste it into
> her database for execution.

Similarly with a script statement to be pasted into FM. There's very
little complicated about splitting a field with consistent data into two
or more other fields.   Even fairly complex conditions aren't that hard
to parse.  

If FM was just like every other tool that supports SQL, there'd be no
need for it nor place in the market. The fact that it doesn't use SQL
for data retrieval is not, in fact, a damning criticism, it's a primary
cause of the ease of use that gets many people building databases at
all. So many times I come into places and people tell me "I tried to use
Access, 'cause it's free, y'know. But  I just couldn't figure anything
out. At least with Filemaker I can get SOMETHING working."

You say "It doesn't support(fsvo "support") SQL" like that's a *bad*
thing. ;)

We say, "whether FM supports SQL or not isn't the point. The point is
that she asked her question in the wrong place."   It would be like my
scampering over to rec.arts.quilting and asking what temperature I
should can my tomatoes at. I might get an answer, but probably not.

Lynn Allen
www.semiotics.com


FM 7 Tip of the Week: External authentication can permit IT departments
to create and manage user accounts which log into FM. Security becomes
the responsiblity of IT, not FM. 

  
0
lynn
6/27/2004 12:54:57 AM
"manet" <pmanet@invivo.edu> wrote

 > it takes a couple of hours tu understand
 > how to replace all that bullshit SQL
 > with simple FMP functions.

It didn't take me that long to see that you are a Filemaker bigot, with a
very narrow view of "database", Manet. Then again, I suppose that it just
possibly could be that it is the vast majority of the database world that is
"out of step" because they don't agree with your narrow view.

 > If they had the use of SQL in FMP, SQL
 > devs would continue to use it. It's not a
 > good idea.

Why don't you forward your suggestion to replace SQL with "the Filemaker
way" to Oracle, Sybase, and IBM (DB2 and Informix), for a start? They need a
good laugh, now and then, just as we do.

  Larry Linson


0
Larry
6/27/2004 1:02:01 AM
"Howard Schlossberg" wrote

 > Well, now you know about this newsgroup,
 > which is more geared toward end users and
 > beginning to intermediate developers.

Well, it is cross-posted to comp.databases.ms-access, which covers the whole
gamut from novice end users to advanced developers, too. Feel free to drop
in or refer them should someone bring you an Access question.

   Larry Linson
   Microsoft Access MVP


0
Larry
6/27/2004 1:05:33 AM
David W. Fenton wrote:


> Can FM do the important task accomplished in that SQL, which is very
> common in a bill of materials, where you have recursive relations
> within records within a single table? 
> 
The answer was yes.
0
42
6/27/2004 2:55:08 AM
David W. Fenton wrote:

> What you're looking for is "event-driven." And all GUI applications
> are, by definition, event-driven. That FM would implement a GUI
> development environment and not hook events to control that
> environment seems to me to show a fundamental design problem. 

It might 'seem' to, but it doesn't prove to be a problem after all.
0
42
6/27/2004 4:13:26 AM
David W. Fenton wrote:

> If all you have to say about SQL is name calling, then we really
> have absolutely nothing to talk about. You don't seem to know enough
> about it to be making any statements about its utility in any
> circumstances. 

Yes... I seem to recall the same arguments being made when Microsoft 
started making people use the mouse.

You want a command line interface to queries; if FM were to provide one 
it would certainly use SQL... seeing as it would be pointlessly 
redundant to devise its own from scratch. But for the time being FM 
doesn't have that.

Its not that a big a loss, especially to FMs target audience. The SQL 
people out there, at least the bright ones, can figure out how not to 
express queries in a command line language and use FMs interactive 
functionality. Is the loss of the command line the end of the world? No. 
Its a handy thing for power users to be sure, and I'd like to see FM 
have a command line query builder myself... but honestly... its not 
required to define queries, not even complicated ones.
0
42
6/27/2004 4:20:58 AM
David W. Fenton wrote:

> lynn@NOT-semiotics.com (Lynn allen) wrote in
> news:1gfyc8m.150efj17p13cwN%lynn@NOT-semiotics.com: 
> 
> 
>>David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>>
>>
>>>I don't see how having it in a FM data field is easier to archive
>>>than having it in the file system. Can you explain?
>>
>>Imagine an image db where only references are stored. Now burn it
>>onto a CD. Oops, all your paths are now invalid. No images
>>display. 
> 
> 
> You have 4GB CDs?

Can we say 'nit-pick'??

We already have plenty of media that can hold 4GB, and the future is 
going to add plenty more.
0
42
6/27/2004 11:45:32 AM
Howard Schlossberg wrote:

> David W. Fenton wrote:
> 
>>>> 2. do you have events that allow you to format data input after
>>>> the input is accepted? 
>>>
>>>
>>> Yes.  FM doesn't call it an event, but yes: just set up an
>>> auto-enter calculation that formats it the way you want.  Whenever
>>> the field value is changed, it will automatically reformat itself
>>> per the developer's specs. 
>>
>>
>>
>> Is that in the table definition or on the screen layout?
> 
> 
> Table definition, which is where it should be.  The idea here (it sounds 
> to me) is for consistancy of data across the board.  Table defintion is 
> therefore where it belongs.  If you want to control it on a per-screen 
> layout, then you can either define that in the table definition or in a 
> per-layout script triggered by the free plug-in.
> 

Or in a utility table with an appropriately defined field.

0
42
6/27/2004 11:47:55 AM
42 <42@nospam.com> wrote in news:wryDc.906847$oR5.827234@pd7tw3no:

> We already have plenty of media that can hold 4GB, and the future is 
> going to add plenty more.

whatever that means ...

-- 
Lyle
(for e-mail refer to http://ffdba.com/)
--
use iso dates
http://www.w3.org/QA/Tips/iso-date
0
Lyle
6/27/2004 12:54:40 PM
MS SQL Server, MySQL, PostgreSQL, Interbase, Sybase, Ingres, Adabas


And maybe this should also be included to cheer up the discussion:
Objectivity/DB

The largest EVER database in the world: 895 TB (yes, terabytes) is
stored in a database supporting SQL++  ...  100 servers, 2000 CPUs

http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml

If I were Manet, I'd rephrase the post into something like

"FM does not support SQL. We see that as a weakness/limitation. But it
has other strength and its own use blah...blah..."

rather than downplaying the role of SQL in database. Which obviously
shows that he's ignorant and didn't have a proper fundamental
knowledge in database theory.

Well, then maybe manet would argue than why need such knowledge to
"develop applications".
;-)

NB
0
nickbose
6/27/2004 1:43:19 PM
> If FM was just like every other tool that supports SQL, there'd be no
> need for it nor place in the market. The fact that it doesn't use SQL
> for data retrieval is not, in fact, a damning criticism, it's a primary
> cause of the ease of use that gets many people building databases at
> all. So many times I come into places and people tell me "I tried to use
> Access, 'cause it's free, y'know. But  I just couldn't figure anything
> out. At least with Filemaker I can get SOMETHING working."
> Lynn Allen
> www.semiotics.com

I think that's exactly coming back to one of my post some time ago
when after some researching, I concluded that FM (version 6 then, I
think) was not suitable for serious database application development.

In the first post in the thread I thought version 7 would have adopted
lots of good Access' features and is worth a re-appraisal now. But
after following the discussion I think FM7 still has some considerable
limitation.

Of course, it doesn't mean FM is no good. It does have its target
market which mostly includes power end-users with simple or maybe
moderately complex business rules/logic requiring an easy-to-learn
tool to make some GUI to stored data. Using other front-end tools
(like Access & VBA) in those scenarios is an overkill, and too steep a
learning curve.


NB
0
nickbose
6/27/2004 2:10:52 PM
"Lyle Fairfield" wrote ...
> 42 wrote :
>
> > We already have plenty of media that can hold 4GB, and the future is
> > going to add plenty more.
>
> whatever that means ...

What is that attitude supposed to get you? DVD burners that write 4.7 gigs are
less than $100.00 and dual-side discs capable of holding 17 gigs are available
now. If you have about $2500.00 to spend, Blue laser Optical discs are shipping
now with 50 Gig capacities on a dual layer device from Sony
(http://www.computerworld.com/hardwaretopics/storage/story/0,10801,92587,00.html
).

It's pretty clear exactly what "42" means above. Your response, however, is
mystifying unless you live under a rock and think the compact disc is the
largest storage medium we'll ever use.

Kent




0
K
6/27/2004 2:31:21 PM
"David W. Fenton"  wrote ...

> I suspect that FM's calculated fields do not store the derived
> value, just the calculation.

> My bet is that, in Access terms, the FM calculated field is much
> like lookup fields in Access table definitions -- derived data is
> calculated on the fly from the formulat and displayed, but with no
> actual duplication of data.

That is the developer's choice in Filemaker. A calculation field in Filemaker
has an option for whether the results should be stored or unstored.

A Lookup field is a different animal in Filemaker, which grabs data from an
external related source and stores it locally. Once in the database, the only
way to change the Lookup data is to modify it yourself, or re-perform the Lookup
based on a given field/relationship.

Kent


0
K
6/27/2004 2:41:53 PM
> I'm not taling about field validation either.  As far as I'm concerned,
> field validation is handled fine by FileMaker's own handling.  But you
> can run event scripts using a free plug-in, triggered by changing a
> field, changing records, clicking into a field, exiting a record...what
> am I missing?

A lot. ;o)


0
Saintor
6/27/2004 7:12:50 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds1krf8h4clc4@corp.supernews.com: 

> I don't see it as an issue.  What do I care if my clients see that
> it's a FileMaker solution.  They've bought at least one seat of
> FileMaker. They know it's not some secret recipe I dreamed up.

For some clients it *is* an issue.

Not for mine, but I've definitely been approached by clients who've
looked at the online screenshots of one of my ancient apps and said
"well, it looks like you used wizards to set it up, so why shouldn't
it just cost a couple hundred dollars?" I replied that there was a
lot more in it than could be created with wizards and if he thought
it was so easy, then he really didn't need to pay me. And I hung up.

Yes, clients can be unreasonable.

And I try not to work with such clients.

But at least Access allows you to work around this kind of minor
issue and package up your app so that it's Access underpinnings are
not painfully visible. 

That said, I still agree that it's a really minor issue and hardly
worth worrying about in a comparison of the two platforms. By
itself, it's certainly trivial. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:12:54 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds1r8ofmint41@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> My question is about FM's native methods for retrieving data, not
>> about how to retrieve data from non-native data sources. 
>> 
>> 1. Can SQL be used to populate data-bearing controls in FM when
>> you are *not* using an ODBC data source (i.e., native FM data)? 
> 
> No, but why would I care?  That's not how you do in FileMaker
> whatever it is that you do in Access.

Well, I understand at this point that this is *not* how it's done in
FM. 

But it took about a dozen attempts at asking the question before I
got a straight answer. 

FM uses data retrieval methods that are proprietary to itself rather
than using an industry-wide languague that is supported by every
other modern database engine I can think of. 

That's good to know.

And it's a huge black mark against FM for those who are already in
the field of database development. 

It's also going to be a big black mark in corporate IT environments
where they are unlikely to want to take on the support of a platform
that has its own idiosyncratic methods, instead of using the
industry-standard methods the IT department is already going to be
familiar with. 

In terms of usability for an indivual developer of FM applications, 
or for the end user just creating her own database application for
personal use, it's not an issue. 

But for anything beyond that, it's a problem.

>> 2. Is SQL supported by FM as a native part of data retrieval,
>> with query optimization and SQL validity checking, or is FM
>> completely ignorant of the internals of any SQL statements sent
>> to an external data source? 
> 
> There is a wizard in FileMaker to help compose SQL as a way of 
> retreiving data from or writing data to external data sources.  It
> does check for grammar.

Grammar? Grammar of what? The SQL grammar? That's good if it does,
but how does it know which dialect of SQL to evaluate? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:16:59 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gg00s9.kk43si1nigwowN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> > as Howard said, I don't think so.
>> > this person can't ever understand that for solving his problem,
>> > she had to look at an FMP competent ressource.
>> > I doubt she can apply any valuable SQL statement. And more, I'm
>> > afraid she would try !
>> 
>> You're simply wrong. Given her table and field names, anyone with
>> SQL knowledge could have written a SQL statement that she could
>> have cut and pasted into her database and executed to update the
>> column. 
> 
> You're simply wrong. She was asking for  help with a Filemaker
> database, and asking in the wrong place.  

I'm not sure what I'm accomplishing here, but I'll repeat it again:

Even in this "wrong place," had FM supported SQL, many people who'd
never used FM could have given her a workable solution to the
problem. 

>> That is, if her database supported SQL.
>> 
>> I don't think you really do understand SQL, or you'd understand
>> that it is trivial for someone to write a valid SQL statement,
>> given the table and field names.
> 
> It's also trivial for someone who knows how to write a script to
> parse data out of a field into two others in FM. If she'd asked
> the correct people, she'd have had her answer in as little time as
> if she'd asked a SQL question in the forum she unfortunately
> chose. 

Well, that she couldn't figure it out with the help of a half dozen
other people who've used FM kind of gives the lie to the idea that
using FM is intuitive and easy, and that writing the script is
trivial. It was not so trivial that she and the people helping her
could figure out how to do it. 

>> And she wouldn't have been required to do anything but paste it
>> into her database for execution.
> 
> Similarly with a script statement to be pasted into FM. There's
> very little complicated about splitting a field with consistent
> data into two or more other fields.   Even fairly complex
> conditions aren't that hard to parse.  

Do you actually read what you're replying to?

I've said repeatedly that the splitting was already done -- she'd
figured out how to use string manipulation to get the individual
parts into calculated fields. What she couldn't figure out how to do
was how to copy that data into their own non-calculated fields. 

And none of the other people who'd used FM was able to explain it,
either. 

> If FM was just like every other tool that supports SQL, there'd be
> no need for it nor place in the market. . . .

I strongly disagree with that. The capability to support SQL behind
the scenes would not change FM's supposed ease of use in foreground
design tasks. 

> . . . The fact that it doesn't
> use SQL for data retrieval is not, in fact, a damning criticism,
> it's a primary cause of the ease of use that gets many people
> building databases at all. So many times I come into places and
> people tell me "I tried to use Access, 'cause it's free, y'know.
> But  I just couldn't figure anything out. At least with Filemaker
> I can get SOMETHING working." 

And I don't think this is a valid criticism of FM any more than I
would say that the ignorant handfull of people who couldn't figure
out how to copy data into new FM fields is by itself a valid
criticism of FM. 

I was only raising the incident as an example of when SQL support in
FM could have been an advantage. 

> You say "It doesn't support(fsvo "support") SQL" like that's a
> *bad* thing. ;)

I think that you'll find outside your narrow FM world that there
will be general agreement that lack of SQL support is considered a
major hole in FM's capabilities. 

> We say, "whether FM supports SQL or not isn't the point. The point
> is that she asked her question in the wrong place."   It would be
> like my scampering over to rec.arts.quilting and asking what
> temperature I should can my tomatoes at. I might get an answer,
> but probably not. 

Well, clearly, there's no point in going on with this exchange.

You're right and I'm wrong.

(and you've done more by taking this stance to drive me away from
considering FM than anything else -- if FM users are all as insular
as you, then it would be pretty hopeless trying to get help as an
Access user migrating to FM) 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:24:14 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds255rdad6t56@corp.supernews.com: 

> David W. Fenton wrote:
> 
>>>it takes a couple of hours tu understand how to replace all that
>>>bullshit SQL with simple FMP functions.
>> 
>> If FM supported SQL, that's a couple of hours that one could be
>> working on a better UI, or on making more attractive layouts, or
>> on any number of other real improvements to an applcation. 
>> 
> David, I'm getting really bored now with this conversation. 
> FileMaker does not use SQL to access its internal data.  It has a
> different way of performing queries.  As I've said, I know SQL and
> any time savings would be minimal.  But it doesn't support SQL
> and, though it might be nice, it really doesn't matter nor do I
> feel that it slows me down in my development.  If you are going to
> insist on using SQL, then do not bother with Filemaker.  It's
> really as simple as that.  Are there other issues that you'd like
> to explore in comparing the two apps?  If not, then I think we're
> done.  Thanks for playing along. 

It took about a dozen posts from me to get a straight answer, that
FM simply does not support SQL. 

This was after a number of posts that claimed it does, each of which
simply misunderstood the question. 

I would speculate that they misunderstood because they are too
insular as FM users to comprehend terminology and techniques from
outside the FM universe. This bodes ills for FM in terms of support
from the user community, especially for someone who is an
experienced Access user who is considering trying out FM. When the
basice question is so fundamentally misunderstood, it indicates that
it would be pretty difficult for an Access user to get help, since
FM users won't even be able to understand the questions. 

FM doesn't use SQL.

That's fine for the audience FM is designed for.

But it really disqualifies FM as a serious database application
development tool. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:28:06 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds37unp6i2lf0@corp.supernews.com: 

> David W. Fenton wrote:
> 
> > Is this "field definition" in the table definition or in the
> > screen layout?
> 
> Field definitions are in the table definition.  If you want
> different validation for the same field on different screens, then
> you can define which layouts get which validation within the
> field's definition. Or else you can add an event via a plug-in to
> the field and use the triggered script to perform
> your validation and do whatever you want.

Sorry, but I don't understand.

You seem to use "field" to mean both the field in the table
definiton and the control on the screen layout that is used to edit
that underlying field. I think you're saying that the field in the
table has its own validation rules and the control on the layout can
have its own custom-defined scripted behaviors, independent of the
underlying field's validation rules. 

Is that correct?

If so, that's good -- the lack of that would be very problematic in
a serious database development tool. 

> I understand how Access does it and that Access is
> object-oriented. . . .

No, Access is not "object-oriented."

So, no, you don't understand.

> . . . Access is somewhat more convenient in this way
> but, in my experience, only if you know VB.  If you know VB and
> you expext uninhibited object-level control, then you do not want
> to use FileMaker.  FileMaker does not do that.

If you mean event-driven, and claiming that FM doesn't really need
the number of events that Access offers, I think you're
fundamentally misunderstanding the basics of GUI design. 

>  From a programming perspective -- and I've said this a couple
>  times 
> before in this thread -- Access is absolutely more powerful and
> more flexible.  That doesn't necessarily make it simpler. . . .

It's simpler if your application requires the more complex solution.
That is, if you really do need to handle distinct parts of the
editing process, and FM doesn't have that granularity of events,
then in FM, you'll have to come up with a workaround. 

The potential complexity of Access may appear to to be a hindrance
to accomplishing simple tasks, but when you need to accomplish a
non-simple task, FM may simply not allow you to do it. 

> . . . But any
> tool is only simple in the hands of someone who knows how to use
> that tool.  I believe my end result solution is equal to yours in
> most respects, as far as the end user is concerned.  I also
> believe that my client can reach that end result much less
> expensively then they could using an Access developer.

I think that these things even out, and that it basically depends
more on the developer than it does on the tool. I've seen Access
apps that cost $5K that I could have done for $2K or less. The
difference is not the tool, but the developer. 

And I think that's far, far more important than anything else.

However, that said, I do think that for the kinds of apps that I
have been asked to create for customers, I probably would have been
unable to do them in FM without kludging the whole thing to work
around FM's lack of granularity of events. 

>> But it still doesn't answer my fundamental question, as it's not
>> clear to me if FM terminology differentiates the term "field"
>> from the term "control" in a data editing layout (a control is
>> the widget used to display and edit the field in the underlying
>> data table). 
> 
> A field is a column, defined as part of the table structure. 
> Fields can also be used as layout objects and can be displayed on
> each layout as either a standard text field, radio buttons,
> checkboxes, dropdown, etc. 

But a field on a layout is not the field in the underlying table.
It's an instance of a control that is used to edit the underlying
data field. It's important to distinguish the two because they will,
of necessity, have different events, precisely because they exist in
completely different contexts. 

>> Events, for instance, don't really belong in data tables, seems
>> to me, since data tables are not UI components. 
> 
> Events are controlled by scripts.  Scripts can be separated out,
> if you'd like, into a separate interface file.  Validation, on the
> other hand, does belong with the data tables; validation controls
> what is and is not allowed in a field -- how many characters
> should it be, should it be allowed if another field is not the
> correct value, etc. . . .

I agree with all of that.

Is field departure an event of a field in a data table or of only
the layout? If the latter, then I think that's the correct design. 

> . . . If you want to consider this as business
> logic -- and I don't doubt that could be argued -- then you are
> free to create a script in the interface or business logic layers
> and design your layouts to run those scripts at the appropriate
> time, using different methods to run the scripts, depending on
> what you want to do.  This is all flexible, but that's the way
> validation and/or other types of scripts are handled.  If you
> prefer the way Access handles these things, then I would recommend
> sticking with Access; FileMaker would not be for you.

If I'm understanding you correctly, FM and Access are basically the
same in this regard. 

However, one difference is that you can define validation rules in a
control on a form that is different from the validation rule in the
underlying table. Why one would do that, I don't know! But it's
possible. I hadn't mentioned it before because I don't consider it
one of those features that really matters much. 

>> Secondly, if only the table definition can define these
>> validation rules, how do you handle cases where the rules are
>> different based on what values have been chosen in other fields
>> for a particular record? In Access, you define that in your form.
>> Can you do the same in FM, or are you limited to defining
>> validation rules within the table? 
> 
> You usually define it within your table, unless you want to script
> it to work only on a particular form.  Either way, you can compare
> as many fields as you want in a record (or with fields in a
> related record or series of records), you can allow it for some
> users and not others, on some layouts and not others -- whatever
> on earth you want to do. 

It sounds to me that, basically, though terminology and exact
methods are different, the separation between validation rules in
the underlying data tables and event handling in forms/layouts is
maintained in FM just as it is in Access. 

That's good -- anything else would have been highly problematic!

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:46:23 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds3eg8j8nuk87@corp.supernews.com: 

> David W. Fenton wrote:
> 
>  > My example in another thread was where I needed two fields to
>  > be 
>> unique. My table has a unique compound key on those two fields,
>> so it's impossible to add duplicate records. But the default Jet
>> error message for this is very user-unfriendly (perhaps FM's
>> default error messages are more user-friendly, or perhaps you can
>> define a custom error message for index violations), so I want to
>> intercept the edit *before* it gets written to the data table. In
>> Access, I do this in the BeforeUpdate event. It sounds like it
>> simply wouldn't be possible in FM, unless the actual updating of
>> the underlying data field doesn't happen until *after* the field
>> departure is complete. 
>> 
>> Can the exit event of your FM field be cancelled?
> 
> Field data is not committed until you exit the record.  Before
> exiting the record, you always have the option to revert that
> record (and any related records that might have been touched from
> a particular layout). 
>   On a per-layout basis, the developer also has the ability to
>   require a 
> user's 'OK' before committing the record.

But what about field-by-field? Can you cancel an edit to a
particular field? 

And when do field-level validation rules fire? When the record is
saved or when the "field" on the layout is exited? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:47:31 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds3kcbbm26ra9@corp.supernews.com: 

> David W. Fenton wrote:
> 
>>>With FileMaker 7, it would primarily be when you enter a portal
>>>row (which is a related record), in which case that foreign
>>>record would be locked AND the current (local) record would be
>>>locked. This does make a lot of sense that it would be this way. 
>>>Clicking into a field does not lock the record.  It only locks as
>>>soon as the first modification is made to any data in the record.
>> 
>> 
>> So, you're saying that for as long as the child record is locked,
>> the parent is also locked? 
>> 
>> That's kind of weird -- I'm having some difficulty coming up with
>> a plausible explanation for why this would be either necessary or
>> useful. Any suggestions? 
> 
> If you are on a particular layout that represents the parent
> record, and you have a portal on that layout that represents a
> child record, and you make a change to any field, then the parent
> record is locked.  If you also edit one of the child fields, then
> that record is also locked. This gives you the opportunity to
> revert the parent record, which would also revert the child
> record.  It assumes that if you are editing on the parent's
> screen, then you intend on that screen's record being locked. 

I'm confused.

If you're editing the parent record, the parent record is locked.

If you're editing the child record, the child record is locked.

My understanding was that editing the child record without any edits
in the parent record would also lock the parent record. I do not
understand why this should be necessary or valuable. 

Have I misunderstood?-

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:49:54 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10ds48el5qk3709@corp.supernews.com: 

> David W. Fenton wrote:
> 
>>>>qryCelkoBOM :
>>>>SELECT P_2.MemberName, Exp(Sum(Log(P_1.Qty))) AS RequiredQty
>>>>FROM P, P AS P_1, P AS P_2
>>>>WHERE (((P.MemberID)=[RootNodeID]) AND ((P_1.lft) Between
>>>>[P].[lft]+1 And [P].[rgt]) AND ((P_2.lft)=[P_2].[rgt]-1 And
>>>>(P_2.lft) Between [P_1].[lft] And [P_1].[rgt]))
>>>>GROUP BY P_2.MemberName;
> 
>> Can FM do the important task accomplished in that SQL, which is
>> very common in a bill of materials, where you have recursive
>> relations within records within a single table? 
>
> Once again, yes.  Looks to me like a search across some
> relationships and a calc field, then sorted and summarized into a
> report layout. 

Um, no, it's rather different from that.

It has to do with adjacencies and resolving nested relationships
into a single, powerful structure. 

Celko has written about this in many times, and this article (not by
Celko) does a pretty good job of explaining it all: 

http://www.sqlteam.com/item.asp?ItemID=8866

The article gives the references to Celko's own articles on the
subject and then goes on to give an implementation of a
non-normalized method for implementing the same thing. I've actually
seen implementations like that, and think they are extremely
wrongheaded, since it violates all of Codd's normal forms. 

But at least it explains the problem space and gives pointers to
Celko's own articles on the subject. 

Can such an adjacency structure be implemented in FM in a manner
that does not limit the depth of the hiearchy? 

That is, could a single solution handle 3 or 4 levels of a
business's oranization chart, but also handle the dozens of levels
of a family tree? Or is the implementation in FM going to have a
hard-wired limit to the number of levels in the hierarchy? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 7:59:34 PM
42 <42@nospam.com> wrote in news:gGqDc.865946$Pk3.441672@pd7tw1no:

> David W. Fenton wrote:
> 
> 
>> Can FM do the important task accomplished in that SQL, which is
>> very common in a bill of materials, where you have recursive
>> relations within records within a single table? 
>
> The answer was yes.

And Dick Cheney still claims Iraq had significant ties with Al
Quaeda, with just as much evidence offered as for your "yes." 

Care to explain how it's done so I could try it out in the FM7 demo?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 8:00:32 PM
42 <42@nospam.com> wrote in news:KWrDc.902910$oR5.594596@pd7tw3no:

> Its not that a big a loss, especially to FMs target audience. The
> SQL people out there, at least the bright ones, can figure out how
> not to express queries in a command line language and use FMs
> interactive functionality. . .. 

The whole point of SQL is that it's *not* a sequential language, so
your citation of "command line language" pretty much negates any
credibility any of your comments on the subject could have. 

> . . . Is the loss of the command line the end
> of the world? No. Its a handy thing for power users to be sure,
> and I'd like to see FM have a command line query builder myself...
> but honestly... its not required to define queries, not even
> complicated ones. 

You don't need to know SQL to use Access, either.

But if you know SQL, you can make Access do more things than if you
don't. 

I'm only suggesting that FM would gain several advantages by
supporting SQL: 

0. first off, assume that, just as with Access, you could still
point and click your way to your resultset without needing to delve
into the SQL. 

1. SQL would offer an alternative method for accomplishing a task.
Sometimes, an alternative is easier to understand. In some cases,
for the person knowledgeable in SQL, they might get to the solution
quicker with SQL than with the standard FM methods. 

2. SQL would allow access to FM's functions with less of a learning
curve for those who already knew SQL, because of the familiarity
with the interface that they'd bring. 

3. SQL would make FM more attractive to IT departments with built-in
SQL expertise. 

4. SQL might be able, as with Access, to provide functionality that
the existing data retrieval UI makes impossible or difficult. 

But it's quite clear to me that the stance taken by the FM users in
this discussion is that, nope, don't need that here. Wouldn't
possibly have any value. Move along. 

And that just looks pigheaded and insular from the outside looking
in. 

And that attitude of the user community seems to me to be as much of
a black mark against FM as the lack of SQL support. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 8:06:28 PM
42 <42@nospam.com> wrote in news:wryDc.906847$oR5.827234@pd7tw3no:

> David W. Fenton wrote:
> 
>> lynn@NOT-semiotics.com (Lynn allen) wrote in
>> news:1gfyc8m.150efj17p13cwN%lynn@NOT-semiotics.com: 
>> 
>>>David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
>>>
>>>>I don't see how having it in a FM data field is easier to
>>>>archive than having it in the file system. Can you explain?
>>>
>>>Imagine an image db where only references are stored. Now burn it
>>>onto a CD. Oops, all your paths are now invalid. No images
>>>display. 
>> 
>> You have 4GB CDs?
> 
> Can we say 'nit-pick'??
> 
> We already have plenty of media that can hold 4GB, and the future
> is going to add plenty more.

You were talking about backup.

There is nothing logically superior about backing up a FM data store
in comparison to backing up folders on a server. 

Indeed, many would think that the latter is vastly superior.

As to the issue of copying just the FM database and forgetting to
copy the files, that's going to be a problem with any
multi-component application. If your FM database connects to two
different FM data stores and you forget to include one of them,
you've got just as much of a problem. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/27/2004 8:08:55 PM
David W. Fenton wrote:

> But what about field-by-field? Can you cancel an edit to a
> particular field? 

Not directly, not after you've gone to another field and not without 
reverting the entire record.  But if, as a developer, it looks as though 
that is goign to be a need, then you set it up differently.  In this 
case, you would set it up so that data is entered into globals 
(variables) and then it is easy enough to restore the original data on a 
per-field basis, if that is what you want.  This has never limited my 
solutions.  And by the way, I cound a couple Fortune 500 companies as my 
clients

> And when do field-level validation rules fire? When the record is
> saved or when the "field" on the layout is exited? 

When field-level validation occurs depends on the type of validation 
that has been defined for a field.  For example, if a field has been set 
to be unique, then validation occurs upon field exit.  If validation has 
been set to happen by calculation, which may (or may not) include 
comparisons to other fields, then validation occurs upon record commit.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 8:24:04 PM
David W. Fenton wrote:

> The article gives the references to Celko's own articles on the
> subject and then goes on to give an implementation of a
> non-normalized method for implementing the same thing. I've actually
> seen implementations like that, and think they are extremely
> wrongheaded, since it violates all of Codd's normal forms. 
> 
> But at least it explains the problem space and gives pointers to
> Celko's own articles on the subject. 
> 
> Can such an adjacency structure be implemented in FM in a manner
> that does not limit the depth of the hiearchy? 
> 
> That is, could a single solution handle 3 or 4 levels of a
> business's oranization chart, but also handle the dozens of levels
> of a family tree? Or is the implementation in FM going to have a
> hard-wired limit to the number of levels in the hierarchy? 

Apologies, but I can't take the time right now to study the article. 
But if by "adjacency structure" and "depth of hierarchy" you are talking 
about levels of relationships and dependencies, FileMaker does handle 
these dependencies through a virtually limitless number of levels.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/27/2004 8:28:31 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> But it really disqualifies FM as a serious database application
> development tool.

It really disqualifies FM as a tool for someone who can only see One
True Database Way.

The rest of us are a bit more flexible, and btw, fully employed and
quite well compensated.

I don't flinch when I have to interface FM and SQL, FM and Quickbooks,
FM and XML, FM and whatever. In other words, I learn each technology ON
ITS OWN MERITS, not "qualifying" any of them as better, worse, or more
less worthy than any other.  I don't insist that I should be able to
develop or query exactly the same way using Oracle or FM. 

It would do you better to do the same than to approach everything from
the viewpoint that if it doesn't do everything EXACTLY like Access or
SQL, then it's less than the dust beneath your chariot wheels.

This discussion has finally gotten to the point of uselessness, since
you don't enquire for any reason but to declare superiority or
inferiority.  In fact, there is no such universal quality in any tool,
but only fitness or lack thereof for a particular task.

Over and out.    

Lynn Allen
0
lynn
6/27/2004 9:19:46 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> It has to do with adjacencies and resolving nested relationships
> into a single, powerful structure.

Actually, it's about giving the user a bill of materials that suits his
needs.  So the answer is, yes, FM can do that.

Just because it doesn't structure or query in EXACTLY the same way
doesn't invalidate the output.

And don't tell me I don't understand the question. I've created
innumerable work order/bill of materials/invoicing/purchase order
systems, most of which are still in use.

Lynn Allen


Lymaree 
0
lynn
6/27/2004 9:19:46 PM
Larry  Linson <bouncer@localhost.not> wrote:

> They need a
> good laugh, now and then, just as we do.

oh yes, I frequently laugh. 

my job is datamining, and I've to cope with many DBs ; that's the usual
way :
- Firstly, I try to use the included reports
- 2nd, I demand to DB adm to give me the reports I need.
- 3rd, after one week of mail exchange, they can't give me what I want.
So I say them : don't panic guys, send me some flat tables and I'll do
the job myself with FMP. The difficult point is to get the good tables.

Once it's done, usually, it takes me a few hours to organize and process
datas...

after 20 years of practice, I can say that few DB designers have some
idea of what is the use of a database. My favorite sentence is : your DB
is in fact a data cemetery.
0
pmanet
6/27/2004 11:19:16 PM
David W. Fenton <dXXXfenton@bway.net.invalid> wrote:

> There's a huge amount
> of mathematical theory behind the design of SQL. 

with time, I've learned not to take attention to mathematical theory,
but to practical results.

observation of people working on the field demonstrates that SQL don't
work in practice.
And I know some exceptions ; they remain exceptions...
0
pmanet
6/27/2004 11:19:16 PM
David W. Fenton wrote:
> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
> news:10ds3kcbbm26ra9@corp.supernews.com: 
> 
> 
>>David W. Fenton wrote:
>>
>>
>>>>With FileMaker 7, it would primarily be when you enter a portal
>>>>row (which is a related record), in which case that foreign
>>>>record would be locked AND the current (local) record would be
>>>>locked. This does make a lot of sense that it would be this way. 
>>>>Clicking into a field does not lock the record.  It only locks as
>>>>soon as the first modification is made to any data in the record.
>>>
>>>
>>>So, you're saying that for as long as the child record is locked,
>>>the parent is also locked? 
>>>
>>>That's kind of weird -- I'm having some difficulty coming up with
>>>a plausible explanation for why this would be either necessary or
>>>useful. Any suggestions? 
>>
>>If you are on a particular layout that represents the parent
>>record, and you have a portal on that layout that represents a
>>child record, and you make a change to any field, then the parent
>>record is locked.  If you also edit one of the child fields, then
>>that record is also locked. This gives you the opportunity to
>>revert the parent record, which would also revert the child
>>record.  It assumes that if you are editing on the parent's
>>screen, then you intend on that screen's record being locked. 
> 
> 
> I'm confused.
> 
> If you're editing the parent record, the parent record is locked.

Yes.

> If you're editing the child record, the child record is locked.

Yes.

> My understanding was that editing the child record without any edits
> in the parent record would also lock the parent record. 

*Only* if you are editing the child through a portal from the parent.

>I do not
> understand why this should be necessary or valuable. 

Because you are editing the child from the parent record. If the parent 
record were to change, it could break the relationship to the child, 
while you were editing the child.

Its a FM specific thing, once you've seen an FM portal in action, it 
would make perfect sense. If you don't want that behaviour just switch 
to the child records, and don't use a portal.


0
42
6/28/2004 12:46:18 AM
David W. Fenton wrote:

> And it's a huge black mark against FM for those who are already in
> the field of database development. 

I find it amusing that being easy enough to use that a non-database 
developer can figure it out is 'a huge black mark'?

But whatever. F-U-D runs rampant... do you fear Linux servers too?

After all most IT departments are still Windows-savvy shops, but if they 
are willing to get the expertise they often find that Linux has a place 
in their corporate world... same with filemaker. But if your going to 
hide in your MS-only, SQL-only shell... well...at least its comfortable.




0
42
6/28/2004 12:55:32 AM
"David W. Fenton"  wrote ...
>
> You were talking about backup.
>
> There is nothing logically superior about backing up a FM data store
> in comparison to backing up folders on a server.
>
> Indeed, many would think that the latter is vastly superior.
>
> As to the issue of copying just the FM database and forgetting to
> copy the files, that's going to be a problem with any
> multi-component application. If your FM database connects to two
> different FM data stores and you forget to include one of them,
> you've got just as much of a problem.

To you, maybe there is no difference between backing up one or more folders and
backing up a single file. To me it is a significant difference in less code,
less error checking, no chance that someone has moved one of the files.

Kent


0
K
6/28/2004 1:01:05 AM
"Saintor" wrote ...
(Someone else that Saintor didn't quote, wrote...
> > I'm not taling about field validation either.  As far as I'm concerned,
> > field validation is handled fine by FileMaker's own handling.  But you
> > can run event scripts using a free plug-in, triggered by changing a
> > field, changing records, clicking into a field, exiting a record...what
> > am I missing?
>
> A lot. ;o)

Saintor, putting a smiley after a smart-ass comeback doesn't change the fact
that your post was devoid of any useful response.

Kent


0
K
6/28/2004 1:03:20 AM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:gGqDc.865946$Pk3.441672@pd7tw1no:
> 
> 
>>David W. Fenton wrote:
>>
>>
>>
>>>Can FM do the important task accomplished in that SQL, which is
>>>very common in a bill of materials, where you have recursive
>>>relations within records within a single table? 
>>
>>The answer was yes.
> 
> 
> And Dick Cheney still claims Iraq had significant ties with Al
> Quaeda, with just as much evidence offered as for your "yes." 
> 
> Care to explain how it's done so I could try it out in the FM7 demo?
> 

FM recursion to arbitrary depth of that type would require a script to 
iterate through the tree. (This accomplishes the 'nesting').

You would accomplish it via a script because there is no gaurantee that 
a circular ('recursive') relationships would ever bottom out, and since 
FM  resolves relationships on the fly as needed (ie performs the query), 
it could stack overflow on simple layout display if the recursion were 
defined improperly, and this is not permitted.

That said, such a script to execute arbitrary depth nested queries and 
accumulate the results would be easy to implement.

Bottom line. Yes. The result set you are looking for can be obtained, 
and its not terribly difficult.
0
42
6/28/2004 1:12:24 AM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:KWrDc.902910$oR5.594596@pd7tw3no:
> 
> 
>>Its not that a big a loss, especially to FMs target audience. The
>>SQL people out there, at least the bright ones, can figure out how
>>not to express queries in a command line language and use FMs
>>interactive functionality. . .. 
> 
> 
> The whole point of SQL is that it's *not* a sequential language, so
> your citation of "command line language" pretty much negates any
> credibility any of your comments on the subject could have. 

I think your confused.

The only non-sequential aspect to SQL is that as a language it allows 
the user to define the 'results' they are looking for, instead of 
specfying how those results are generated.

e.g.
select name, age, school from mytable where name='bob' orderby age;

Says i want the records from mytable where name=bob, sorted by age. It 
doesn't tell the SQL implementation *how* to get that table, it leaves 
that to the implementation to figure out. That is the *only* 
non-sequential thing about it.

A series of sql statements are executed in sequence, and are designed to 
be input via a command line. That makes it a command line language.



> 
>>. . . Is the loss of the command line the end
>>of the world? No. Its a handy thing for power users to be sure,
>>and I'd like to see FM have a command line query builder myself...
>>but honestly... its not required to define queries, not even
>>complicated ones. 
> 
> 
> You don't need to know SQL to use Access, either.
> 
> But if you know SQL, you can make Access do more things than if you
> don't. 

With FM you can do those other things without sql too.

> I'm only suggesting that FM would gain several advantages by
> supporting SQL: 
<snip>
  to me that the stance taken by the FM users in
> this discussion is that, nope, don't need that here. Wouldn't
> possibly have any value. Move along. 

Nope. You are mistaken, AGAIN.

The stance is that SQL isn't required to construct an arbitrary query. 
Period. Nobody ever said it wouldn't have any value.

Big difference!

Most of us would be pleased if FM offered SQL natively as an alternative 
  for when it is more convenient.

Its like the difference between spanish and english.

Your jumping up and  down saying well in *MY language English* we can 
say 'la di da'... can you say that in 'Spanish'? And we say yes. And 
then you say... "but its not english, and I speak english, so its a huge 
black mark against you because I can't apply my english". To which we 
say, "its spanish, learn spanish, its just as rich a language, and 
simpler to learn too".

We've never said english sucks, we've never said it has no possible 
value, we've just said that, "Hey, you can get your point accross in 
spanish too".

> And that just looks pigheaded and insular from the outside looking
> in. 

The 'outside looking in' is being more than its share of pigheaded.

> And that attitude of the user community seems to me to be as much of
> a black mark against FM as the lack of SQL support. 

Your arrogant combatitive stance would speak volumes for the Access 
community too... but fortunately we're enlightened enough to know that 
its just you, not Access that deserves the black mark.

Cheers,
-42
0
42
6/28/2004 1:37:49 AM
Fair enough.  But in your case we don't need a smiley to see that you are an
idiot.


"K&V P" <random_characters@shaw.ca.invalid> wrote in message
news:s7KDc.882639$Pk3.641928@pd7tw1no...
>
> "Saintor" wrote ...
> (Someone else that Saintor didn't quote, wrote...
> > > I'm not taling about field validation either.  As far as I'm
concerned,
> > > field validation is handled fine by FileMaker's own handling.  But you
> > > can run event scripts using a free plug-in, triggered by changing a
> > > field, changing records, clicking into a field, exiting a
record...what
> > > am I missing?
> >
> > A lot. ;o)
>
> Saintor, putting a smiley after a smart-ass comeback doesn't change the
fact
> that your post was devoid of any useful response.
>
> Kent
>
>



0
Saintor
6/28/2004 2:16:20 AM
"Saintor" wrote ...
> "K&V P" wrote ...
> > "Saintor" wrote ...
> > (Someone else that Saintor didn't identify, wrote...
> > > > I'm not talking about field validation
> > > > either.  As far as I'm concerned,
> > > > field validation is handled fine by
> > > > FileMaker's own handling.  But you
> > > > can run event scripts using a free
> > > > plug-in, triggered by changing a
> > > > field, changing records, clicking
> > > > into a field, exiting a record...what
> > > > am I missing?
> > > A lot. ;o)
> > Saintor, putting a smiley after a smart-ass
> > comeback doesn't change the fact
> > that your post was devoid of any useful response.

> Fair enough.  But in your case we don't need a smiley
> to see that you are an idiot.


OK, my "smart-ass" comment probably earned me a negative rebuttal as it was
slightly cheap, but really? What did I ever do that made you feel it's
appropriate to say that "we" can see that I'm an idiot?

A philosophy prof taught me that two of the most successful counters to a
statement you want to refute are:

1) Provide counter information that negates it.
2) Launch a personal attack at the opponent, aimed at getting people to laugh at
them so the audience fails to notice that you have no point to make.

Despite my (rather mild) dig, all I did was point out that your post was devoid
of usefulness. I didn't imply anything about you personally, nor did I invite
the appellation of "idiot."

I hope the readers see where my opinion of you is headed at the moment.

Kent


0
K
6/28/2004 3:31:03 AM
I teach relational database theory from time to time, and the one area
where FileMaker absoutuley destroys SQL-based systems is in the full
outer join problem.

To whit,

By default, JOINs in SQL are INNER joins, i.e. they only return the
matching rows from both tables.   No match?  Both records are gone.
One-sided outer joins are possible in Access, but (last time I checked)
full outer joins were not.

Failing to do a full outer join when needed can lead to dire
consequences -- instead of null values in certain fields, you lose
entire records from the results.   It's a subtle and hard to detect
error.

Explaining to students the difference between outer and inner joins is
not easy; nor is the fact that actually performing one is not easy
either.

FileMaker handles this problem in a weirdly elegant way : by design, you
tend to create calculated fields instead of using joins.  The failure
mode is much safer (if there is no related record, you just get blank
data on a per-field basis, and you don't lose the records on both sides
of the relationship).

I tend to think of FileMaker as, in some ways, more like LISP or APL:
functional (by which I mean data manipulation is 'composed of
functions').   SQL / Access / PHP combinations tend to be much more
procedural in nature (i.e. data maniuplation is done via procedures).

This is not to say that I love FileMaker :  I'm just getting into
version 7, and for the most part, some of its most obvious faults have
been fixed.   But a few long-term glaringly obvious limitations still
remain (e.g. would it really have been that hard for them to support
mouse scroll wheels under Mac OS X!)

-- 
To send email, remove the invalid and nospams.
0
md03NOSPAM
6/28/2004 5:20:05 AM
On Sun, 27 Jun 2004 22:20:05 -0700, md03NOSPAM@xochiNOSPAM.com.invalid
(Michael Diehr) wrote:

>I teach relational database theory from time to time, and the one area
>where FileMaker absoutuley destroys SQL-based systems is in the full
>outer join problem.
>
>To whit,
>
>By default, JOINs in SQL are INNER joins, i.e. they only return the
>matching rows from both tables.   No match?  Both records are gone.
>One-sided outer joins are possible in Access, but (last time I checked)
>full outer joins were not.
>
>Failing to do a full outer join when needed can lead to dire
>consequences -- instead of null values in certain fields, you lose
>entire records from the results.   It's a subtle and hard to detect
>error.
>
>Explaining to students the difference between outer and inner joins is
>not easy; nor is the fact that actually performing one is not easy
>either.

I agree the issue exists, but I don't see it as that common of an issue.  I
come up with the need for a full outer join once in perhaps 3 or 4 large
applications.  When I do need one, there's a way to do it with a UNION query,
and if you don't know how, you can find out in any of several FAQs.

>FileMaker handles this problem in a weirdly elegant way : by design, you
>tend to create calculated fields instead of using joins.  The failure
>mode is much safer (if there is no related record, you just get blank
>data on a per-field basis, and you don't lose the records on both sides
>of the relationship).

And using calculated fields instead of joins is a good thing?  What if there
are multiple fields based on the same relationship?  What if there is another
join from that join?  Not to mention, why would you want to have queries
written in a syntax that only applies to one database product?  I frequently
design queries in Access, then use the SQL to query other relational database,
pretty much unmodified - or vice verse.

>I tend to think of FileMaker as, in some ways, more like LISP or APL:
>functional (by which I mean data manipulation is 'composed of
>functions').   SQL / Access / PHP combinations tend to be much more
>procedural in nature (i.e. data maniuplation is done via procedures).

Well, when you're writing script code, sure, but most of Access is based on
SQL queries (though the user need not be aware of the SQL language) which are
4GL and much more like functional code than procedural code.  By the way, how
is a calculated field more like functional than procedural?  Sounds like going
in the opposite direction to me.

>This is not to say that I love FileMaker :  I'm just getting into
>version 7, and for the most part, some of its most obvious faults have
>been fixed.   But a few long-term glaringly obvious limitations still
>remain (e.g. would it really have been that hard for them to support
>mouse scroll wheels under Mac OS X!)

Yeah, I notice that only about 2/3 of OS X programs understand the scroll
wheel.  I imagine that means it's not well integrated into the OS X API, so
perhaps later OS X updates will fix the issue in other programs.
0
Steve
6/28/2004 6:23:06 AM
David W. Fenton wrote:
> 
> Do the textbox controls in FM have a rich event model, or are you
> limited only to the characteristics of the fields bound to them? 
> 

Basically what I was trying to say is, for a lot of things, it doesn't 
matter. It solved the example problem you provided - and that's the 
whole point - to get something done. As I said, I'm sure you can come up 
with a more difficult example, but the one you provided can be done, 
just in a different way.
0
Kevin
6/28/2004 1:18:56 PM
David W. Fenton wrote:


> What I'm asking for is not "very specific and unusual."
> 
> It's basic data entry validation.
> 
> It can also be done with very little code in Access, and often
> without writing any. But some very common circumstances make the
> ability to distinguish the sequence of events that happen when a
> user edits data essential. 

But what manet was trying to say is that you keep giving examples and 
telling us the method to do them in Access and then assume because FM 
doesn't use that method then the task cannot be done. But usually it 
can. And so far in this thread, every example that I've seen you provide 
can easily be done in FM.
0
Kevin
6/28/2004 1:22:48 PM
Howard Schlossberg wrote:

> 
> Running a script upon field exit can be done with a free plug-in 
> provided with FileMaker Developer.  It is not a third-party plugin.
> 

Really? I haven't noticed that. I stand corrected.

What is the plug-in called? Is it installed by default?
0
Kevin
6/28/2004 1:25:01 PM
David W. Fenton wrote:


> If so, that's good -- the lack of that would be very problematic in
> a serious database development tool. 

Can we at least cut the arrogance in this discussion? It's obvious that 
you are not that familiar with FM, so going through a checklist of 
Access and discounting FM as "not a serious tool" every time you come 
across something is not justified. People use FM every day with ease to 
make working database solutions for end users - that, and only that, 
make is a serious database development tool.

It's good that you are making an effort to learn about FM, and I'm sorry 
if I sound harsh, but statements like that are really annoying to those 
that use FM to earn a living.
0
Kevin
6/28/2004 1:30:11 PM
Saintor wrote:

>>You went nuts because you didn't know how to do something?  
> 
> 
> **And** because the help files and support groups were zero
> assistance.

It's right there in the help files under field validation. It's also in 
the manual.
0
Kevin
6/28/2004 1:32:22 PM
David W. Fenton wrote:
> 
> 
> You have 4GB CDs?
> 

DVDs then. Her argument still stands.
0
Kevin
6/28/2004 1:35:25 PM
David W. Fenton wrote:


> 
> I suspect that FM's calculated fields do not store the derived
> value, just the calculation. 
> 

You have made an incorrect assumption. The developer can choose whether 
or not FM stores/indexes the results of a calculation field.
0
Kevin
6/28/2004 1:41:50 PM
It is not installed by default -- and it's not very easy to find unless 
you are looking for it -- but you'll find it onthe Developer CD at 
\English Extras\Examples\FMExample\FMPlugInSDK\Example\WinExample.fmx


Kevin Hayes wrote:

> Howard Schlossberg wrote:
> 
>>
>> Running a script upon field exit can be done with a free plug-in 
>> provided with FileMaker Developer.  It is not a third-party plugin.
>>
> 
> Really? I haven't noticed that. I stand corrected.
> 
> What is the plug-in called? Is it installed by default?

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 2:19:53 PM
Oh, my.  Access doesn't run cross-platform?  That is quite problematic. 
  Access must not be a serious database tool for anyone working in an 
office where they might have any Macs.

And Access doesn't have web capabilities built right in to it?  Oh my. 
Everyone's using the web these days and expects to be able to easily 
make their data available via the web.  This is quite problematic.  I 
can't imagine that any serious database tool wouldn't do that.  Access 
is obviously not a serious data tool.  FileMaker has its very powerful 
Instant Web Publishing, as well as its custom web publishing using XML 
and XSLT.  The API also supports ODBC, JDBC and XML calls.  In fact, 
FileMaker has strongly supported XML since version 5.5.

Except for one person, I haven't seen any FM users say that it wouldn't 
be nice for SQL to be built into FMP for internal data access.  I and 
others would certainly use it.  But it certainly isn't a show-stopper 
for anyone.  There are ways, David, to do everything you have so far 
proposed (except having FMP query itself specifically using SQL).

And it's just as well that all you people won't be moving into FMP until 
it does self-querying SQL, as I make quite a nice living in building FMP 
solutions for some major-sized companies.  I wouldn't want all these 
other people infringing on my market.

Kevin Hayes wrote:

> David W. Fenton wrote:
> 
> 
>> If so, that's good -- the lack of that would be very problematic in
>> a serious database development tool. 
> 
> 
> Can we at least cut the arrogance in this discussion? It's obvious that 
> you are not that familiar with FM, so going through a checklist of 
> Access and discounting FM as "not a serious tool" every time you come 
> across something is not justified. People use FM every day with ease to 
> make working database solutions for end users - that, and only that, 
> make is a serious database development tool.
> 
> It's good that you are making an effort to learn about FM, and I'm sorry 
> if I sound harsh, but statements like that are really annoying to those 
> that use FM to earn a living.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 2:39:14 PM
One other thing.  Does Access run on Linux?  No?  How can a product be 
serious unless it is available across all the popular platforms?! 
FileMaker has been available for Linux since version 5.0.  FMP 7 is not 
yet out for Linux, but it is expected soon.  Doesn't that make Access 
kind of proprietary since it only runs on its developer's own operating 
system?  This is quite problematic.

Howard Schlossberg wrote:

> Oh, my.  Access doesn't run cross-platform?  That is quite problematic. 
>  Access must not be a serious database tool for anyone working in an 
> office where they might have any Macs.
> 
> And Access doesn't have web capabilities built right in to it?  Oh my. 
> Everyone's using the web these days and expects to be able to easily 
> make their data available via the web.  This is quite problematic.  I 
> can't imagine that any serious database tool wouldn't do that.  Access 
> is obviously not a serious data tool.  FileMaker has its very powerful 
> Instant Web Publishing, as well as its custom web publishing using XML 
> and XSLT.  The API also supports ODBC, JDBC and XML calls.  In fact, 
> FileMaker has strongly supported XML since version 5.5.
> 
> Except for one person, I haven't seen any FM users say that it wouldn't 
> be nice for SQL to be built into FMP for internal data access.  I and 
> others would certainly use it.  But it certainly isn't a show-stopper 
> for anyone.  There are ways, David, to do everything you have so far 
> proposed (except having FMP query itself specifically using SQL).
> 
> And it's just as well that all you people won't be moving into FMP until 
> it does self-querying SQL, as I make quite a nice living in building FMP 
> solutions for some major-sized companies.  I wouldn't want all these 
> other people infringing on my market.
> 
> Kevin Hayes wrote:
> 
>> David W. Fenton wrote:
>>
>>
>>> If so, that's good -- the lack of that would be very problematic in
>>> a serious database development tool. 
>>
>>
>>
>> Can we at least cut the arrogance in this discussion? It's obvious 
>> that you are not that familiar with FM, so going through a checklist 
>> of Access and discounting FM as "not a serious tool" every time you 
>> come across something is not justified. People use FM every day with 
>> ease to make working database solutions for end users - that, and only 
>> that, make is a serious database development tool.
>>
>> It's good that you are making an effort to learn about FM, and I'm 
>> sorry if I sound harsh, but statements like that are really annoying 
>> to those that use FM to earn a living.
> 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 2:43:02 PM
Howard Schlossberg wrote:

> It is not installed by default -- and it's not very easy to find unless 
> you are looking for it -- but you'll find it onthe Developer CD at 
> \English Extras\Examples\FMExample\FMPlugInSDK\Example\WinExample.fmx
> 

Thanks. I'll have another look. I hope I find a Mac version too.
0
Kevin
6/28/2004 3:49:43 PM
In article <cbhlk1$a9t$1@zcars0v6.ca.nortel.com>, Kevin Hayes
<me@here.com> wrote:

> David W. Fenton wrote:
> 
> > "Glenn Schwandt" <schwandtg-at@aol-dot.com> wrote in
> > news:10doh1j8gqf6r2b@corp.supernews.com: 
> 
> > This was one of the things that struck me about the discussion I
> > described of the poor FM end-user who couldn't figure out how to
> > copy data from a calculated field into a real field -- they were
> > speaking in terms that didn't translate well, and left the rest of
> > us who had no FM experience unable to help. 
> 
> Seems like the problem is that she was asking the wrong people for help. 
> I see your point, but it's not valid due to there being FM help readily 
> available. (this newsgroup, for example).

I would disagree with that. Filemaker uses very idiosyncratic
nomenclature (e.g., a table is not called a table) and while there
is obviously nothing to be done about it at this point, it's
unfortunate and unhelpful.

> What if her problem was with Access development and there were only 
> Oracle developers around?

Well, at least everyone would agree that a table is a table.

> You wouldn't start a campaign saying Access should work exactly
> like Oracle, would you?

Of course not. But it seems to me that one of the problems Filemaker
users have when talking to people who understand databases but don't
use Filemaker is that they use such idiosyncratic, Filemaker-specific
terms that it's difficult to communicate clearly.

--
0
jdoherty
6/28/2004 6:14:10 PM
John Doherty wrote:
>>Seems like the problem is that she was asking the wrong people for help. 
>>I see your point, but it's not valid due to there being FM help readily 
>>available. (this newsgroup, for example).
> 
> I would disagree with that. Filemaker uses very idiosyncratic
> nomenclature (e.g., a table is not called a table) and while there
> is obviously nothing to be done about it at this point, it's
> unfortunate and unhelpful.

Well, this seems like a petty arguement.  But regardless, a table has 
always been a table -- it's just that non-database experts don't 
understand that it is called a table.  In prior versions of FileMaker, 
there was one table per file.  With Filemaker 7, each file can have 
multiple tables.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 7:17:12 PM
In article <10e0rlsv778p8c@corp.supernews.com>, Howard Schlossberg
<howard@antispahm.fmprosolutions.com> wrote:

> John Doherty wrote:
> >>Seems like the problem is that she was asking the wrong people for help. 
> >>I see your point, but it's not valid due to there being FM help readily 
> >>available. (this newsgroup, for example).
> > 
> > I would disagree with that. Filemaker uses very idiosyncratic
> > nomenclature (e.g., a table is not called a table) and while there
> > is obviously nothing to be done about it at this point, it's
> > unfortunate and unhelpful.
> 
> Well, this seems like a petty arguement.

That would be one opinion. Mine is what I said: that the terminology
used within Filemaker is idiosyncratic and unhelpful.

It would be one thing if there were no well-known, widely-used terms
used to discuss databases, but there are: Filemaker just doesn't use
them, or uses them in non-standard ways.

It's almost as if someone designing a word processor decided to
use the terms "words," "sentences," and "paragraphs" to refer
to things other than words, sentences, and paragraphs. Sure, you
can adjust, but it's pointless and unhelpful -- the terminology
used by Filemaker isn't any better, it's just idiosyncratic.

--
0
jdoherty
6/28/2004 9:07:00 PM
Steve Jorgensen <nospam@nospam.nospam> wrote:

> On Sun, 27 Jun 2004 22:20:05 -0700, md03NOSPAM@xochiNOSPAM.com.invalid
> (Michael Diehr) wrote:
> 
> >I teach relational database theory from time to time, and the one area
> >where FileMaker absoutuley destroys SQL-based systems is in the full
> >outer join problem.
> >
> >To whit,
> >
> >By default, JOINs in SQL are INNER joins, i.e. they only return the
> >matching rows from both tables.   No match?  Both records are gone.
> >One-sided outer joins are possible in Access, but (last time I checked)
> >full outer joins were not.
> >
> >Failing to do a full outer join when needed can lead to dire
> >consequences -- instead of null values in certain fields, you lose
> >entire records from the results.   It's a subtle and hard to detect
> >error.
> >
> >Explaining to students the difference between outer and inner joins is
> >not easy; nor is the fact that actually performing one is not easy
> >either.
> 
> I agree the issue exists, but I don't see it as that common of an issue.  I
> come up with the need for a full outer join once in perhaps 3 or 4 large
> applications.  When I do need one, there's a way to do it with a UNION query,
> and if you don't know how, you can find out in any of several FAQs.
>

The frequency of outer join use is probably content-dependent.  I've
worked on a system where we needed them all the time, and the lack of
true full-outer joins wreaked havoc with an entire laboratory. 
 
> >FileMaker handles this problem in a weirdly elegant way : by design, you
> >tend to create calculated fields instead of using joins.  The failure
> >mode is much safer (if there is no related record, you just get blank
> >data on a per-field basis, and you don't lose the records on both sides
> >of the relationship).
> 
> And using calculated fields instead of joins is a good thing?  What if there
> are multiple fields based on the same relationship?  What if there is another
> join from that join?

FM7 can reference any field in any related record, no matter how many
relationships you have to "tunnel" through.   So something that may take
a 5 table SQL join "just works" in FM.

>  Not to mention, why would you want to have queries
> written in a syntax that only applies to one database product?  I frequently
> design queries in Access, then use the SQL to query other relational database,
> pretty much unmodified - or vice verse.
> 

Again, depends on content.  I rarely find that there's enough similarty
in the underlying problems I'm solving to re-use code, so that doesn't
bother me.

> >I tend to think of FileMaker as, in some ways, more like LISP or APL:
> >functional (by which I mean data manipulation is 'composed of
> >functions').   SQL / Access / PHP combinations tend to be much more
> >procedural in nature (i.e. data maniuplation is done via procedures).
> 
> Well, when you're writing script code, sure, but most of Access is based on
> SQL queries (though the user need not be aware of the SQL language) which are
> 4GL and much more like functional code than procedural code.  

It's a different paradigm: In FileMaker, the user interface design IS
the query in many ways.  In other words, when you've built the UI, the
query is essentially done for you.

FYI, somewhat off topic, here is a critique that claims that SQL is
actually a very poor model of the underlying relational model.  I've not
read the article yet, but I sense it's saying something that I agree
with:  Basically, SQL is not good about handling complex relational
scenarios (such as outer joins, multi-value keys, NULL values, etc).
The calculated-field / functional paradigm of FileMaker seems to make
many of these problems dissappear magically.

<http://developers.slashdot.org/article.pl?sid=04/06/28/1728204&mode=thr
ead&tid=126>

> By the way, how
> is a calculated field more like functional than procedural?  Sounds like going
> in the opposite direction to me.

How to explain it.  I guess I'd say that FM is more object-oriented (in
this particular way) than access.   Instead of writing a procedure
(SetFieldXXXCalculatedValue) and then calling it with events, the
function is built into the field itself.
 
> >This is not to say that I love FileMaker :  I'm just getting into
> >version 7, and for the most part, some of its most obvious faults have
> >been fixed.   But a few long-term glaringly obvious limitations still
> >remain (e.g. would it really have been that hard for them to support
> >mouse scroll wheels under Mac OS X!)
> 
> Yeah, I notice that only about 2/3 of OS X programs understand the scroll
> wheel.  I imagine that means it's not well integrated into the OS X API, so
> perhaps later OS X updates will fix the issue in other programs.

It's particularily annoying, given that FileMaker used to be Apple /
Claris.  You'd think they might still have some connections back at
Apple to get the SDK...


-- 
To send email, remove the invalid and nospams.
0
md03NOSPAM
6/28/2004 9:21:22 PM
42 <42@nospam.com> wrote in news:80KDc.882580$Pk3.738240@pd7tw1no:

> David W. Fenton wrote:
> 
>> And it's a huge black mark against FM for those who are already
>> in the field of database development. 
> 
> I find it amusing that being easy enough to use that a
> non-database developer can figure it out is 'a huge black mark'?

You spend a lot of time coming up with imaginary interpretations of
what other people say? 

I think FM is a fine tool for non-database developers.

It also seems to be a pretty usable tool for many database
developers who've learned how to use it. 

If it supported SQL it would perhaps be a suitable development
platform for a larger number of developers. 

> But whatever. F-U-D runs rampant... do you fear Linux servers too?

What makes you think I would?

> After all most IT departments are still Windows-savvy shops, but
> if they are willing to get the expertise they often find that
> Linux has a place in their corporate world... same with filemaker.
> But if your going to hide in your MS-only, SQL-only shell...
> well...at least its comfortable. 

Do you think that calling for SQL is a de facto MS-only declaration?
If so, then you really don't have a clue about what I've been
talking about from beginning to end. SQL is something that MS
categorically does not control, thank heavens. 

It's seems that it's useless to try to discuss things with some of
you FM folks because you seem to know so little about anything but
FM that you don't even understand the conversations of people
developing database apps using other tools. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:30:52 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gg1kjy.iwsvbczzavjoN%lynn@NOT-semiotics.com: 

> It would do you better to do the same than to approach everything
> from the viewpoint that if it doesn't do everything EXACTLY like
> Access or SQL, then it's less than the dust beneath your chariot
> wheels. 

I didn't say it had to do it "exactly like" anything else.

I did suggest that not supporting the universally used data
manipulation language of every serious database platform of the last
15-20 years doesn't do much to make it look like a serious database
development platform. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:32:10 PM
In message <jdoherty-2806041314100001@192.168.2.178>, John Doherty 
<jdoherty@nowhere.null.not> writes


>Of course not. But it seems to me that one of the problems Filemaker
>users have when talking to people who understand databases but don't
>use Filemaker is that they use such idiosyncratic, Filemaker-specific
>terms that it's difficult to communicate clearly.

That's not a problem unique to Filemaker, and I suspect most other 
database management systems. For instance Access calls a view a query 
:-)

I think it's just something you have to live with when you work with 
software from different suppliers. By the time you are working on your 
sixth or seventh operating system and ninth or tenth programming 
language you sort of get to expect these things.




-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

0
Bernard
6/28/2004 9:34:31 PM
Kevin Hayes <me@here.com> wrote in
news:cbp6cb$qjg$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> If so, that's good -- the lack of that would be very problematic
>> in a serious database development tool. 
> 
> Can we at least cut the arrogance in this discussion? It's obvious
> that you are not that familiar with FM, . .. 

I've not claimed familiarity, so why my lack of it should be held
against me, I don't know. 

I'm trying to learn enough to see if it's worth my while seriously
trying it out. 

> . . . so going through a
> checklist of Access and discounting FM as "not a serious tool"
> every time you come across something is not justified. . . .

Er, controlling user interaction in terms of GUI events is not by
any stretch of the imagination an Access-only issue. 

> . . . People use
> FM every day with ease to make working database solutions for end
> users - that, and only that, make is a serious database
> development tool. 
> 
> It's good that you are making an effort to learn about FM, and I'm
> sorry if I sound harsh, but statements like that are really
> annoying to those that use FM to earn a living.

I'm glad you can make a living at it.

I'm sorry you can't see that Access developers are attached to some
of the techniques we use not because they are what we know, but
because they make development of user-friendly, robust database
applications fast and efficient. I'm just trying to figure out if FM
does things the same way or accomplishes the same tasks in a
different manner. I'm sorry if I failed to adopt FM terminology, or
if my questions betray my long-time connections with Access. 

I don't really see any way around that problem, so I don't quite get
why I come under criticism for it. 

Tone, well, I have tone problems, yes -- my CDMA colleagues often
criticize my tone, as well. 

But I don't think there has been anything wrong with the substance
of my questions, however much I might have been more diplomatic in
asking them. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:36:39 PM
In message <Xns9516B26DC55B1dfentonbwaynetinvali@24.168.128.86>, David 
W. Fenton <dXXXfenton@bway.net.invalid> writes
>lynn@NOT-semiotics.com (Lynn allen) wrote in
>news:1gg1kjy.iwsvbczzavjoN%lynn@NOT-semiotics.com:
>
>> It would do you better to do the same than to approach everything
>> from the viewpoint that if it doesn't do everything EXACTLY like
>> Access or SQL, then it's less than the dust beneath your chariot
>> wheels.
>
>I didn't say it had to do it "exactly like" anything else.
>
>I did suggest that not supporting the universally used data
>manipulation language of every serious database platform of the last
>15-20 years doesn't do much to make it look like a serious database
>development platform.

To nitpick: I don't use Filemaker but I understand that it has an ODBC 
interface, which means that it supports SQL and there are ways of 
passing SQL commands to it. It's the standard GUI that doesn't support 
SQL.



-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

0
Bernard
6/28/2004 9:37:26 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e0bclpjfmn814@corp.supernews.com: 

[]

That's the end for me.

You aren't really serious about learning anything one way or the
other. 

Indeed, I haven't seen anyone from the FM side of things trying to
learn more about Access. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:38:00 PM
42 <42@nospam.com> wrote in news:uTJDc.882463$Pk3.501240@pd7tw1no:

> David W. Fenton wrote:

>> If you're editing the parent record, the parent record is locked.
> 
> Yes.
> 
>> If you're editing the child record, the child record is locked.
> 
> Yes.
> 
>> My understanding was that editing the child record without any
>> edits in the parent record would also lock the parent record. 
> 
> *Only* if you are editing the child through a portal from the
> parent. 
> 
>>I do not
>> understand why this should be necessary or valuable. 
> 
> Because you are editing the child from the parent record. If the
> parent record were to change, it could break the relationship to
> the child, while you were editing the child.

Any field in the parent record, or just the fields on which the two
records are related? 

> Its a FM specific thing, once you've seen an FM portal in action,
> it would make perfect sense. If you don't want that behaviour just
> switch to the child records, and don't use a portal.

Is a "portal" a subform?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:39:58 PM
lynn@NOT-semiotics.com (Lynn allen) wrote in
news:1gg1l5w.1e18r0ol6uxvkN%lynn@NOT-semiotics.com: 

> David W. Fenton <dXXXfenton@bway.net.invalid> wrote:
> 
>> It has to do with adjacencies and resolving nested relationships
>> into a single, powerful structure.
> 
> Actually, it's about giving the user a bill of materials that
> suits his needs.  So the answer is, yes, FM can do that.
> 
> Just because it doesn't structure or query in EXACTLY the same way
> doesn't invalidate the output.
> 
> And don't tell me I don't understand the question. I've created
> innumerable work order/bill of materials/invoicing/purchase order
> systems, most of which are still in use.

You have avoided answering the actual question.

I guess it would be wrong or unfair of me to take that as evidence
that FM cannot actually do what was asked or that you don't
understand the question. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:41:09 PM
42 <42@nospam.com> wrote in news:YfKDc.882729$Pk3.603976@pd7tw1no:

> David W. Fenton wrote:
> 
>> 42 <42@nospam.com> wrote in
>> news:gGqDc.865946$Pk3.441672@pd7tw1no: 
>> 
>>>David W. Fenton wrote:
>>>>
>>>>Can FM do the important task accomplished in that SQL, which is
>>>>very common in a bill of materials, where you have recursive
>>>>relations within records within a single table? 
>>>
>>>The answer was yes.
>> 
>> And Dick Cheney still claims Iraq had significant ties with Al
>> Quaeda, with just as much evidence offered as for your "yes." 
>> 
>> Care to explain how it's done so I could try it out in the FM7
>> demo? 
> 
> FM recursion to arbitrary depth of that type would require a
> script to iterate through the tree. (This accomplishes the
> 'nesting'). 

But the whole point of the adjacency model is that it is *not*
sequential processing. 

Yes, it can be accomplished through sequential processing, but
that's always much more processing-intensive than set methods. 

> You would accomplish it via a script because there is no gaurantee
> that a circular ('recursive') relationships would ever bottom out,
> and since FM  resolves relationships on the fly as needed (ie
> performs the query), it could stack overflow on simple layout
> display if the recursion were defined improperly, and this is not
> permitted. 
> 
> That said, such a script to execute arbitrary depth nested queries
> and accumulate the results would be easy to implement.
> 
> Bottom line. Yes. The result set you are looking for can be
> obtained, and its not terribly difficult.

But you are admitting that it can't be done via the efficient
adjacency method, but only through sequential processing. 

At least, you personally do not know how to do it any other way (no
slur intended on your knowledge of FM by that, either). 

In any given application, sequential processing may be just fine,
but in certain kinds of circumstances, it may just not work at all.
And I don't even think it takes that many levels or that many total
number of records for the performance drain of sequential processing
to become obvious. 

OK, I've got as much information here as I need to know. I'll stop
banging on this issue. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:46:03 PM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:80KDc.882580$Pk3.738240@pd7tw1no:
> 
> 
>>David W. Fenton wrote:
>>
>>
/cut_1
>>>And it's a huge black mark against FM for those who are already
>>>in the field of database development. 
/end_cut_1
>>
>>I find it amusing that being easy enough to use that a
>>non-database developer can figure it out is 'a huge black mark'?
> 

/cut_2>
> You spend a lot of time coming up with imaginary interpretations of
> what other people say? 
/end_cut_2

> I think FM is a fine tool for non-database developers.
> 
> It also seems to be a pretty usable tool for many database
> developers who've learned how to use it. 
> 
> If it supported SQL it would perhaps be a suitable development
> platform for a larger number of developers. 

The same would be true if it could be embadded into C applications. I 
fail to see that supporting SQL natively is a holy grail it should 
strive for. It would be useful sure...but something to get worked up 
about? Hardly. If you *want* to use SQL, use a different tool.

Nobody intelligent uses a screwdriver when they need a wrench, and 
nobody would tell a screwdriver its got 'huge black marks against it' 
because its a lousy wrench.

> 
>>But whatever. F-U-D runs rampant... do you fear Linux servers too?
> 
> 
> What makes you think I would?

Because it sounds exactly like something else you said:

/paste_1
 >>>And it's a huge black mark against FM for those who are already
 >>>in the field of database development.
/end_paste_1

To paraphrase... "And its a huge black mark against [Linux Servers] for 
those who are already in the field of [Windows Servers]".



> 
>>After all most IT departments are still Windows-savvy shops, but
>>if they are willing to get the expertise they often find that
>>Linux has a place in their corporate world... same with filemaker.
>>But if your going to hide in your MS-only, SQL-only shell...
>>well...at least its comfortable. 
> 
> 
> Do you think that calling for SQL is a de facto MS-only declaration?

zing... right over your head. The point was that an IT shop that lacks a 
given technology expertise and thus fears and rejects that technology 
does so to its own detriment.

Linux technology to a Windows savvy IT shop is a mirror analagy to FM in 
a sql savvy it shop. Managing to somehow assert that I said SQL is a MS 
anything is truly perverse, bravo!

> If so, then you really don't have a clue about what I've been
> talking about from beginning to end. SQL is something that MS
> categorically does not control, thank heavens. 

Since you brought the whole MS-controlling-SQL topic up, its worth 
pointing out that SQL is like HTML as far as MS strategy goes: Extend 
and conquer.

> It's seems that it's useless to try to discuss things with some of
> you FM folks because you seem to know so little about anything but
> FM that you don't even understand the conversations of people
> developing database apps using other tools. 

/paste_2
 > You spend a lot of time coming up with imaginary interpretations of
 > what other people say?
/end_paste_2

I couldn't have said it better myself.
0
42
6/28/2004 9:50:54 PM
42 <42@nospam.com> wrote in news:NDKDc.919538$oR5.617328@pd7tw3no:

> David W. Fenton wrote:
> 
>> 42 <42@nospam.com> wrote in
>> news:KWrDc.902910$oR5.594596@pd7tw3no: 
>> 
>> 
>>>Its not that a big a loss, especially to FMs target audience. The
>>>SQL people out there, at least the bright ones, can figure out
>>>how not to express queries in a command line language and use FMs
>>>interactive functionality. . .. 
>> 
>> 
>> The whole point of SQL is that it's *not* a sequential language,
>> so your citation of "command line language" pretty much negates
>> any credibility any of your comments on the subject could have. 
> 
> I think your confused.
> 
> The only non-sequential aspect to SQL is that as a language it
> allows the user to define the 'results' they are looking for,
> instead of specfying how those results are generated.
> 
> e.g.
> select name, age, school from mytable where name='bob' orderby
> age; 
> 
> Says i want the records from mytable where name=bob, sorted by
> age. It doesn't tell the SQL implementation *how* to get that
> table, it leaves that to the implementation to figure out. That is
> the *only* non-sequential thing about it.
> 
> A series of sql statements are executed in sequence, and are
> designed to be input via a command line. That makes it a command
> line language. 

You would only make such an argument if you had no understand of the
difference between sequential processing and set operations. 

I'm not going to take the time to educate you on the mathematical
theory behind SQL, so let's just leave it at that. 

>>>. . . Is the loss of the command line the end
>>>of the world? No. Its a handy thing for power users to be sure,
>>>and I'd like to see FM have a command line query builder
>>>myself... but honestly... its not required to define queries, not
>>>even complicated ones. 
>> 
>> You don't need to know SQL to use Access, either.
>> 
>> But if you know SQL, you can make Access do more things than if
>> you don't. 
> 
> With FM you can do those other things without sql too.

Well, it appears you can't use the adjacency method for generating
nested recursive hierarchies. In any particular application, that
may not matter (assuming the number of records involved and the
number of levels does not bog things down), but it is easy to
imagine applications in which it would be a show-stopper. 

[]

I'm done here, at least on this topic.

I've learned enough to conclude that it's probably not worth my
while devoting any significant amount of time looking at FM. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:51:27 PM
David W. Fenton wrote:


> I did suggest that not supporting the universally used data
> manipulation language of every serious database platform of the last
> 15-20 years doesn't do much to make it look like a serious database
> development platform. 
> 

Shucks, I bet all the COBOL programmers said that when C came out too.
0
42
6/28/2004 9:51:47 PM
Kevin Hayes <me@here.com> wrote in
news:cbp5n8$pda$2@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
>> 
>> Do the textbox controls in FM have a rich event model, or are you
>> limited only to the characteristics of the fields bound to them? 
> 
> Basically what I was trying to say is, for a lot of things, it
> doesn't matter. It solved the example problem you provided - and
> that's the whole point - to get something done. As I said, I'm
> sure you can come up with a more difficult example, but the one
> you provided can be done, just in a different way.

I have not seen anyone post an explanation of how the situation in
my example would be handled in FM, except for some mumbled
references to field validation rules, which is pretty much missing
the whole point. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:55:54 PM
Kevin Hayes <me@here.com> wrote in
news:cbp5ug$pda$3@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> What I'm asking for is not "very specific and unusual."
>> 
>> It's basic data entry validation.
>> 
>> It can also be done with very little code in Access, and often
>> without writing any. But some very common circumstances make the
>> ability to distinguish the sequence of events that happen when a
>> user edits data essential. 
> 
> But what manet was trying to say is that you keep giving examples
> and telling us the method to do them in Access and then assume
> because FM doesn't use that method then the task cannot be done.
> But usually it can. And so far in this thread, every example that
> I've seen you provide can easily be done in FM.

And, yet, no one has actually taken the time to post an explanation
of *how* it is done in FM. 

Given that fact, is my skepticism really that hard to understand?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 9:56:52 PM
In article <0dQBeIHn7I4AFwdx@shrdlu.com>, Bernard Peek <bap@shrdlu.com> wrote:

> In message <jdoherty-2806041314100001@192.168.2.178>, John Doherty 
> <jdoherty@nowhere.null.not> writes
> 
> 
> >Of course not. But it seems to me that one of the problems Filemaker
> >users have when talking to people who understand databases but don't
> >use Filemaker is that they use such idiosyncratic, Filemaker-specific
> >terms that it's difficult to communicate clearly.
> 
> That's not a problem unique to Filemaker, and I suspect most other 
> database management systems. For instance Access calls a view a query 
> :-)

Now that's *really* unhelpful. ;-)

--
0
jdoherty
6/28/2004 9:58:31 PM
Kevin Hayes <me@here.com> wrote in
news:cbp6gf$qjg$2@zcars0v6.ca.nortel.com: 

> Saintor wrote:
> 
>>>You went nuts because you didn't know how to do something?  
>> 
>> **And** because the help files and support groups were zero
>> assistance.
> 
> It's right there in the help files under field validation. It's
> also in the manual.

Field-level validation rules do not replace the BeforeUpdate and
AfterUpdate events of controls in Access. 

Not to mention, OnChange, OnEnter, OnExit, MouseOver, MouseDown,
MouseUp, KeyDown, KeyUp, KeyPress, GotFocus, LostFocus, OnClick or
OnDoubleClick. 

For instance, how in FM can you filter a dropdown list based on user
input, and have the dropdown list match your typed choices? 

The built-in Access dropdown list by defaults matches as you type,
so if you type "m" the first entry beginning with "m" is selected.
If you then type "a" you are taken to the first entry beginning with
"ma". 

Now, in cases with dropdown lists that would have very long lists if
unfiltered, you might want to populate them only after the user had
typed two or three characters. So, you might have them type "ma"
then populate the dropdown only with the items starting with "ma." 

In the first case, match as you type, it's a built-in default
property of the dropdown list, and a very user-friendly one, at
that. 

In the second case, you can easily implement it in the OnChange
event, testing the length of typed-in value and setting the dropdown
list's rowsource only after the required number of characters has
been typed. 

Can it be done in FM?

If so, how?

The HOW is important.

A number of questions of the form "can FM do X" has been asked, and
all we get in return are assertions that yes, FM can do X, but no
explanations of how (though we keep hearing that field validation
rules seem to solve all problems and give FM just as much
flexibility as all those silly events in Access controls). 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:05:10 PM
Kevin Hayes <me@here.com> wrote in
news:cbp726$qjg$7@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> I suspect that FM's calculated fields do not store the derived
>> value, just the calculation. 
> 
> You have made an incorrect assumption. The developer can choose
> whether or not FM stores/indexes the results of a calculation
> field. 

And the default?

If the default is to store the data, then FM is a very stupidly
designed program. Allowing the storage of the calculated value, but
not defaulting to it at least puts the blame for the stupidity on
the developer who chooses to store it. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:06:08 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e0rlsv778p8c@corp.supernews.com: 

> John Doherty wrote:
>>>Seems like the problem is that she was asking the wrong people
>>>for help. I see your point, but it's not valid due to there being
>>>FM help readily available. (this newsgroup, for example).
>> 
>> I would disagree with that. Filemaker uses very idiosyncratic
>> nomenclature (e.g., a table is not called a table) and while
>> there is obviously nothing to be done about it at this point,
>> it's unfortunate and unhelpful.
> 
> Well, this seems like a petty arguement.  But regardless, a table
> has always been a table -- it's just that non-database experts
> don't understand that it is called a table.  In prior versions of
> FileMaker, there was one table per file.  With Filemaker 7, each
> file can have multiple tables.

This particular person with the problem had no difficulties with the
terminology. She's a web developer and has actually worked with a
number of database-driven websites, so she knows the basics of
database terminology. 

But the task, copying data from a calculated field into a new, empty
field, was one that a half dozen FM users could not figure out. 

If FM is so user-friendly that people who know nothing about
databases can use it, you'd think this handful of non-technical
users would be able to figure it out. 

If FM did SQL, though, they would have had their answer, and it
could have come from an Oracle user, a MySQL developer, a Sybase
DBA, an MS SQL Server user or even from a lowly Access developer. As
it was, this person was limited to getting useful assistance from
people with experince using FM, and, alas (however hard it might be
for experienced FM developers to believe), she never seems to have
gotten a proper answer. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:10:40 PM
David W. Fenton wrote:
> 42 <42@nospam.com> wrote in news:YfKDc.882729$Pk3.603976@pd7tw1no:

>>FM recursion to arbitrary depth of that type would require a
>>script to iterate through the tree. (This accomplishes the
>>'nesting'). 
> 
> But the whole point of the adjacency model is that it is *not*
> sequential processing. 
> 
> Yes, it can be accomplished through sequential processing, but
> that's always much more processing-intensive than set methods. 

42 is incorrect on this.  No scripting is necessary to drill down 
through as many relationships as you'd like.  Once the relationships 
have been set up, you can get data from anywhere in the chain by just 
referring to the desired table occurence.  No long SQL strings to piece 
it all together.  It just works.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:13:05 PM
David W. Fenton wrote:

>>>Do the textbox controls in FM have a rich event model, or are you
>>>limited only to the characteristics of the fields bound to them? 
>>
>>Basically what I was trying to say is, for a lot of things, it
>>doesn't matter. It solved the example problem you provided - and
>>that's the whole point - to get something done. As I said, I'm
>>sure you can come up with a more difficult example, but the one
>>you provided can be done, just in a different way.
> 
> I have not seen anyone post an explanation of how the situation in
> my example would be handled in FM, except for some mumbled
> references to field validation rules, which is pretty much missing
> the whole point. 
> 
I think YOU have missed the point.  No, there are not per-layout (form) 
object controls for validation, per se.  But scripts (macros) can be 
triggered by changing field content, or upon exiting a layout (form).  I 
don't see what kind of answer you are looking for if that doesn't do it. 
  There are no object-driven events, but there are plenty of ways to 
accomplish what you want.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:16:48 PM
"David W. Fenton"  wrote ...

> And the default?
>
> If the default is to store the data, then FM is a very stupidly
> designed program. Allowing the storage of the calculated value, but
> not defaulting to it at least puts the blame for the stupidity on
> the developer who chooses to store it.

I don't understand why you are so bitter towards Filemaker (or is it the whole
world?). When someone says it doesn't do something, and we say it does and
here's how to do it, you say it probably does it by default then and must
therefore be "a very stupidly designed program."

What's with that?

You assume that it will be the way you don't want it.

You assume the way you don't want it is stupid.

Virtually every line you type is condescending and/or provocative. I don't
understand why anyone ever wants to communicate with you, except for those of us
that enjoy arguing for its own sake.

I think your entire contribution can be summed up as "It doesn't do what I said
I want the way I said I want it to so it's a useless piece of shit and I'm
sticking my head in the sand now so go away"

Access is a good tool
Dbase is a good tool
Filemaker is a good tool
Oracle is a good tool

The four have a lot of things in common and some things that are different. So
don't use Oracle, Filemaker or DBase. I assure you, most of us that do will be
just as happy with that decision.

Kent


0
K
6/28/2004 10:23:52 PM
Bernard Peek <bap@shrdlu.com> wrote in
news:6N8CanHW+I4AFw8u@shrdlu.com: 

> In message <Xns9516B26DC55B1dfentonbwaynetinvali@24.168.128.86>,
> David W. Fenton <dXXXfenton@bway.net.invalid> writes
>>lynn@NOT-semiotics.com (Lynn allen) wrote in
>>news:1gg1kjy.iwsvbczzavjoN%lynn@NOT-semiotics.com:
>>
>>> It would do you better to do the same than to approach
>>> everything from the viewpoint that if it doesn't do everything
>>> EXACTLY like Access or SQL, then it's less than the dust beneath
>>> your chariot wheels.
>>
>>I didn't say it had to do it "exactly like" anything else.
>>
>>I did suggest that not supporting the universally used data
>>manipulation language of every serious database platform of the
>>last 15-20 years doesn't do much to make it look like a serious
>>database development platform.
> 
> To nitpick: I don't use Filemaker but I understand that it has an
> ODBC interface, which means that it supports SQL and there are
> ways of passing SQL commands to it. It's the standard GUI that
> doesn't support SQL.

And the FM users posting in this thread have said that the FM data
engine is a very poor performer when accessed from its ODBC
interface. 

At least, that's what I understood them to say.

And that an FM could not access FM data via the ODBC interface (just
as Access can't connect to Jet via ODBC). 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:25:08 PM
David W. Fenton wrote:

> Field-level validation rules do not replace the BeforeUpdate and
> AfterUpdate events of controls in Access. 
> 
> Not to mention, OnChange, OnEnter, OnExit, MouseOver, MouseDown,
> MouseUp, KeyDown, KeyUp, KeyPress, GotFocus, LostFocus, OnClick or
> OnDoubleClick. 

I don't know how much clearer I can explain it.  I've already mentioned 
the ability to trigger scripts upon exiting a field.  But otherwise, 
there are no true object event control things.  Fields aren't commited 
until the record is committed.  There is no OnExit, no Mouse events 
whatsoever, no keyboard events, focus events, etc.  Most of those can be 
emulated through scripting and a plug-in.

So -- to summarize this entire discussion: FileMaker can do what you 
want and expect, but it does not do it in the same way you are used to.

> For instance, how in FM can you filter a dropdown list based on user
> input, and have the dropdown list match your typed choices? 

You can set up related value lists so that what appears in a list is 
based on a value selected in another field.  This has nothing to do with 
events.  It has to do with how you set up your value lists.

> The built-in Access dropdown list by defaults matches as you type,
> so if you type "m" the first entry beginning with "m" is selected.
> If you then type "a" you are taken to the first entry beginning with
> "ma". 

 > In the first case, match as you type, it's a built-in default
 > property of the dropdown list, and a very user-friendly one, at
 > that.

Same here.

> Now, in cases with dropdown lists that would have very long lists if
> unfiltered, you might want to populate them only after the user had
> typed two or three characters. So, you might have them type "ma"
> then populate the dropdown only with the items starting with "ma." 
> 
> In the second case, you can easily implement it in the OnChange
> event, testing the length of typed-in value and setting the dropdown
> list's rowsource only after the required number of characters has
> been typed. 
> 
> Can it be done in FM?

No, this cannot be done in FileMaker because there is no click or type 
event.  It can be emulated, but not very gracefully.  But an alternative 
interface design would be to provide a pop-up window with a portal, 
which is filtered by entries into a global field.  Type as many letters 
as you want and it will display only the records that match what you've 
typed.  But since fields don't update until you've left the field, you 
have to type what you want and then click 'enter'.  Admittedly not as 
graceful as what you have in Access.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:27:25 PM
Bernard Peek <bap@shrdlu.com> wrote in
news:0dQBeIHn7I4AFwdx@shrdlu.com: 

> In message <jdoherty-2806041314100001@192.168.2.178>, John Doherty
><jdoherty@nowhere.null.not> writes
> 
> 
>>Of course not. But it seems to me that one of the problems
>>Filemaker users have when talking to people who understand
>>databases but don't use Filemaker is that they use such
>>idiosyncratic, Filemaker-specific terms that it's difficult to
>>communicate clearly. 
> 
> That's not a problem unique to Filemaker, and I suspect most other
> database management systems. For instance Access calls a view a
> query 
>:-)

An Access query is not just a view.

And generic SQL terminology uses the term "query" the same way
Access does. 

> I think it's just something you have to live with when you work
> with software from different suppliers. By the time you are
> working on your sixth or seventh operating system and ninth or
> tenth programming language you sort of get to expect these things.

I think most of us who use Access on a regular basis are pretty
familiar with Access's indiosyncratic uses of terminology and when
in non-Access contexts are able to adapt pretty well to the norms of
those contexts. 

Indeed, many of us who program in Access now started out programming
on some other database platform beforehand. I wouldn't suggest that
there are not plenty of such FM developers around, but ones with
extensive experience outside FM don't seem to have been
participating in the present discussion. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:27:47 PM
What on earth do you care what the default is.  The blame is on the 
developer who needs to choose whether it should be stored or unstored 
based on its need.  Storage of calcs means they can be indexed, which 
means that searches on those fields are incredibly fast and it means 
those calcs can be used as part of a relationship.

David W. Fenton wrote:

>>You have made an incorrect assumption. The developer can choose
>>whether or not FM stores/indexes the results of a calculation
>>field. 
> 
> 
> And the default?
> 
> If the default is to store the data, then FM is a very stupidly
> designed program. Allowing the storage of the calculated value, but
> not defaulting to it at least puts the blame for the stupidity on
> the developer who chooses to store it. 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:29:38 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e15vlh2q79602@corp.supernews.com: 

> David W. Fenton wrote:
>> 42 <42@nospam.com> wrote in
>> news:YfKDc.882729$Pk3.603976@pd7tw1no: 
> 
>>>FM recursion to arbitrary depth of that type would require a
>>>script to iterate through the tree. (This accomplishes the
>>>'nesting'). 
>> 
>> But the whole point of the adjacency model is that it is *not*
>> sequential processing. 
>> 
>> Yes, it can be accomplished through sequential processing, but
>> that's always much more processing-intensive than set methods. 
> 
> 42 is incorrect on this.  No scripting is necessary to drill down 
> through as many relationships as you'd like.  Once the
> relationships have been set up, you can get data from anywhere in
> the chain by just referring to the desired table occurence.  No
> long SQL strings to piece it all together.  It just works.

You consider the original SQL string posted in this threadlet to be
*long*? I have SQL strings that are over 2K in length. 

I'm not proud of them, though, and don't mention them except to make
a point. ;) 

I'm still curious what you mean by "once the relationships have been
set up." I assume you can set up a recursive relationship in FM (one
needs only one level of this in the RI declaration)? 

How, though, would you get a set of rows that included all people at
all levels in the hierarchy (which means that some people might
occur more than once)? Celko's solution provides that, and I'm not
sure from the responses of the FM users to the whole issue that they
really comprehend exactly what the problem space really is. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:31:06 PM
David W. Fenton wrote:

> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
> news:10e0rlsv778p8c@corp.supernews.com: 

>>Well, this seems like a petty arguement.  But regardless, a table
>>has always been a table -- it's just that non-database experts
>>don't understand that it is called a table.  In prior versions of
>>FileMaker, there was one table per file.  With Filemaker 7, each
>>file can have multiple tables.
> 
> This particular person with the problem had no difficulties with the
> terminology. She's a web developer and has actually worked with a
> number of database-driven websites, so she knows the basics of
> database terminology. 
> 
> But the task, copying data from a calculated field into a new, empty
> field, was one that a half dozen FM users could not figure out. 
> 
> If FM is so user-friendly that people who know nothing about
> databases can use it, you'd think this handful of non-technical
> users would be able to figure it out. 

This discussion is starting to bore me, as well.  Splitting field data 
into multiple fields is simple in FileMaker, given consistant data 
patterns.  And I can't see how it would be any more difficult than 
Access in parsing less consistant data.

If you ask a FileMaker question in an Access forum, then you are not 
really asking knowledged FM users, are you?  I'd imagine that if someone 
asked how to do the same thing in Access, but asked in the FileMaker 
forum, she might have gotten the same sound of stupidity.  I don't see 
how that reflects on FileMaker or its users.

> If FM did SQL, though, they would have had their answer, and it
> could have come from an Oracle user, a MySQL developer, a Sybase
> DBA, an MS SQL Server user or even from a lowly Access developer. As
> it was, this person was limited to getting useful assistance from
> people with experince using FM, and, alas (however hard it might be
> for experienced FM developers to believe), she never seems to have
> gotten a proper answer. 

I still haven't seen it asked here in the FM newsgroup.  Do you want an 
answer on her behalf?  Let me know if the HOW is important here.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:35:16 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e166l3hv448ec@corp.supernews.com: 

> David W. Fenton wrote:
> 
>>>>Do the textbox controls in FM have a rich event model, or are
>>>>you limited only to the characteristics of the fields bound to
>>>>them? 
>>>
>>>Basically what I was trying to say is, for a lot of things, it
>>>doesn't matter. It solved the example problem you provided - and
>>>that's the whole point - to get something done. As I said, I'm
>>>sure you can come up with a more difficult example, but the one
>>>you provided can be done, just in a different way.
>> 
>> I have not seen anyone post an explanation of how the situation
>> in my example would be handled in FM, except for some mumbled
>> references to field validation rules, which is pretty much
>> missing the whole point. 
>> 
> I think YOU have missed the point.  No, there are not per-layout
> (form) object controls for validation, per se.  But scripts
> (macros) can be triggered by changing field content, or upon
> exiting a layout (form).  I don't see what kind of answer you are
> looking for if that doesn't do it. 
>   There are no object-driven events, but there are plenty of ways
>   to 
> accomplish what you want.

Well, leaving multiple value-validation operations to the time the
record is saved is a bad user interface, it seems to me. It's an
old-style mainframe kind of approach, where you edit a screen on a
dumb client, then submit the edited fields to the mainframe where
the whole record is evaluated and any errors sent back to you. We
all live with this kind of thing in web pages these days, because
it's just too hard to do client-side data entry field validation.
And it's really annoying to submit a form of data and then get back
a list of the invalid entries. It's much more user-friendly to not
allow invalid data to be entered into the text controls in the first
place. 

Now, you say that there are exit events that can be used when a
text-editing control is exited, and that would probably take care of
the vast majority of cases. But I can imagine it getting kind of
complicated if you needed to do any number of relatively routine
things. Not impossible, no, but needlessly Byzantine in comparison
to an environment with a richer event model. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/28/2004 10:35:54 PM
Howard Schlossberg wrote:

> David W. Fenton wrote:
> 
>> 42 <42@nospam.com> wrote in news:YfKDc.882729$Pk3.603976@pd7tw1no:
> 
> 
>>> FM recursion to arbitrary depth of that type would require a
>>> script to iterate through the tree. (This accomplishes the
>>> 'nesting'). 
>>
>>
>> But the whole point of the adjacency model is that it is *not*
>> sequential processing.
>> Yes, it can be accomplished through sequential processing, but
>> that's always much more processing-intensive than set methods. 
> 
> 
> 42 is incorrect on this.  No scripting is necessary to drill down 
> through as many relationships as you'd like.  Once the relationships 
> have been set up, you can get data from anywhere in the chain by just 
> referring to the desired table occurence.  No long SQL strings to piece 
> it all together.  It just works.

Howard, I respectfully disagree, and suspect its because you've 
misunderstood the requirement of the problem.

Its not _merely_ drilling down into a relationship of a relationship of 
a relationship. Its recursively drilling down into the *same* 
relationship multiple times.

FM defines this as a circular definition, and this is disallowed.

For example... if I were define simple table with 3 fields, <id, 
childid, accumulator>, and define a relationship from childid->id.

And my table looked like this:

1, 2, 5
2, 3, 6
3, 4, 8
4, null, 5

record 1 is related to record 2.
record 2 is related to record 3.
record 3 is related to record 4.

How do I determine the 'depth' of the relationship from record 1. (the 
answer is 3 deep). How do I determine the sum of the accumultor through 
the depth of the relationship. (its 5+6+8+5=24).

FM must use iterative methods to do this.

The reason FM disallows it directly is because I could set record 4 to 
be: <4,1,5>. And now the recursion doesn't bottom out. Depth is infinite!

This is analogous to the adjacency problem that DWF describes, although 
its simpler because its a linear recursion, whereas the adjacency 
problem can branch at each level.

Please review and respond,
thanks,



0
42
6/28/2004 10:36:48 PM
Apologies to all in the FileMaker newsgroup who have been subjected to 
this discussion.  It started out nicely enough.  An Access user wanted 
to understand how FileMaker worked.  Then it became argumentative.  I've 
now filtered out that discussion and all cross-posts.  Back to our 
regularly scheduled discussions, as far as I'm concerned...

David W. Fenton wrote:

> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
> news:10e166l3hv448ec@corp.supernews.com: 
> 
> 
>>David W. Fenton wrote:
>>
>>
>>>>>Do the textbox controls in FM have a rich event model, or are
>>>>>you limited only to the characteristics of the fields bound to
>>>>>them? 
>>>>
>>>>Basically what I was trying to say is, for a lot of things, it
>>>>doesn't matter. It solved the example problem you provided - and
>>>>that's the whole point - to get something done. As I said, I'm
>>>>sure you can come up with a more difficult example, but the one
>>>>you provided can be done, just in a different way.
>>>
>>>I have not seen anyone post an explanation of how the situation
>>>in my example would be handled in FM, except for some mumbled
>>>references to field validation rules, which is pretty much
>>>missing the whole point. 
>>>
>>
>>I think YOU have missed the point.  No, there are not per-layout
>>(form) object controls for validation, per se.  But scripts
>>(macros) can be triggered by changing field content, or upon
>>exiting a layout (form).  I don't see what kind of answer you are
>>looking for if that doesn't do it. 
>>  There are no object-driven events, but there are plenty of ways
>>  to 
>>accomplish what you want.
> 
> 
> Well, leaving multiple value-validation operations to the time the
> record is saved is a bad user interface, it seems to me. It's an
> old-style mainframe kind of approach, where you edit a screen on a
> dumb client, then submit the edited fields to the mainframe where
> the whole record is evaluated and any errors sent back to you. We
> all live with this kind of thing in web pages these days, because
> it's just too hard to do client-side data entry field validation.
> And it's really annoying to submit a form of data and then get back
> a list of the invalid entries. It's much more user-friendly to not
> allow invalid data to be entered into the text controls in the first
> place. 
> 
> Now, you say that there are exit events that can be used when a
> text-editing control is exited, and that would probably take care of
> the vast majority of cases. But I can imagine it getting kind of
> complicated if you needed to do any number of relatively routine
> things. Not impossible, no, but needlessly Byzantine in comparison
> to an environment with a richer event model. 
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg              (818) 883-2846
FM Pro Solutions       Los Angeles, California
Associate Member, FileMaker Solutions Alliance
0
Howard
6/28/2004 10:43:40 PM
Kevin Hayes <me@here.com> wrote:

> I hope I find a Mac version too.

please, if you find, let me know...
0
pmanet
6/28/2004 10:45:39 PM
David W. Fenton wrote:

> 42 <42@nospam.com> wrote in news:NDKDc.919538$oR5.617328@pd7tw3no:
> 
> 
>>David W. Fenton wrote:
>>
>>
>>>42 <42@nospam.com> wrote in
>>>news:KWrDc.902910$oR5.594596@pd7tw3no: 
>>>
>>>
>>>
>>>>Its not that a big a loss, especially to FMs target audience. The
>>>>SQL people out there, at least the bright ones, can figure out
>>>>how not to express queries in a command line language and use FMs
>>>>interactive functionality. . .. 
>>>
>>>
>>>The whole point of SQL is that it's *not* a sequential language,
>>>so your citation of "command line language" pretty much negates
>>>any credibility any of your comments on the subject could have. 
>>
>>I think your confused.
>>
>>The only non-sequential aspect to SQL is that as a language it
>>allows the user to define the 'results' they are looking for,
>>instead of specfying how those results are generated.
>>
>>e.g.
>>select name, age, school from mytable where name='bob' orderby
>>age; 
>>
>>Says i want the records from mytable where name=bob, sorted by
>>age. It doesn't tell the SQL implementation *how* to get that
>>table, it leaves that to the implementation to figure out. That is
>>the *only* non-sequential thing about it.
>>
>>A series of sql statements are executed in sequence, and are
>>designed to be input via a command line. That makes it a command
>>line language. 
> 
> 
> You would only make such an argument if you had no understand of the
> difference between sequential processing and set operations. 

I would *love* to hear you expand on that.

> I'm not going to take the time to educate you on the mathematical
> theory behind SQL, so let's just leave it at that. 

It would be needless. The mathematical model behind SQL is relational 
calculus. The mathematical theory of which is ultimately a branch of set 
theory. Moreover it is not terribly difficult, although definitions tend 
  to be typically mathematically rigorous.

The only question that remains is not my understanding of database 
design theory, but why you think a discussion of the mathematical theory 
behind SQL is germane to the discussion at hand at all.


> 
>>>>. . . Is the loss of the command line the end
>>>>of the world? No. Its a handy thing for power users to be sure,
>>>>and I'd like to see FM have a command line query builder
>>>>myself... but honestly... its not required to define queries, not
>>>>even complicated ones. 
>>>
>>>You don't need to know SQL to use Access, either.
>>>
>>>But if you know SQL, you can make Access do more things than if
>>>you don't. 
>>
>>With FM you can do those other things without sql too.
> 
> 
> Well, it appears you can't use the adjacency method for generating
> nested recursive hierarchies. In any particular application, that
> may not matter (assuming the number of records involved and the
> number of levels does not bog things down), but it is easy to
> imagine applications in which it would be a show-stopper. 

The adjacency method, whether implemented iteratively by the developer, 
or handed to you on a platter for free by the query processor is still 
ultimately being done the same way. The query processor would be faster 
primarily because its an interpreted script. Just because you can 
declare the query  elegantly in a nested recursive sql statement doesn't 
make it magically able to solve the problem better or faster.

Its the same problem, with the same space time complexity, SQL is just a 
more elegant way of expressing it. Its not some magical thing that can 
actually do anything non-sequentially, it just shields you the developer 
from having to know how its done.

> I've learned enough to conclude that it's probably not worth my
> while devoting any significant amount of time looking at FM. 

You seem hell bent on doing things with it that it is not the optimal 
tool for, with little regard for its benefits when it *is* the optimal tool.

Still, I'll think of you next time I click the 'enable instant web 
publishing' box, or deploy a solution to a mixed PC/Mac shop.

Not to mention the next time I pick up a pair of pliers to turn a screw, 
having concluded that screwdrivers aren't worth devoting serious time 
to, at least not for a pliers expert like myself =)
0
42
6/28/2004 11:04:01 PM
42 wrote:
/fix
  The query processor would be faster primarily because its

*NOT*

an interpreted script.
/end_fix

0
42
6/28/2004 11:17:56 PM
David W. Fenton wrote:
> Kevin Hayes <me@here.com> wrote in
> news:cbp5ug$pda$3@zcars0v6.ca.nortel.com: 

> 
> And, yet, no one has actually taken the time to post an explanation
> of *how* it is done in FM. 

Solutions to several questions of yours have been provided. If you mean 
to your friends query one field and paste into different fields, no that 
hasn't been provided yet. But so what? Do you think we would lie and 
that it's really difficult? If so, then there's no point for you to even 
post here at all. Here's how to do it: (assuming there are spaces 
between the values, if there are other characters delimiting the values, 
or various ways to determine the separate values, then that can be 
calculated too)

Loop
   Setfield(littleField1, middleword(bigField, 1))
   SetField(littleField2, middleword(bigField, 2))
   ...
   SetField(littleFieldn, middleword(bigField, n))
   GoToNext(Exit after Last)
End

> Given that fact, is my skepticism really that hard to understand?

Yes, it is. You didn't ask for the answer. You asked if it could be 
done. You were told it could easily be done. If you doubted us, you 
should have said so several posts ago.
0
Kevin
6/29/2004 12:46:13 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbp6cb$qjg$1@zcars0v6.ca.nortel.com: 

> I'm trying to learn enough to see if it's worth my while seriously
> trying it out. 

No, you are not. You are being argumentative for the sake of arguing. 
You can't seem to grasp the concept that FM works differently. Everytime 
it is explained to you, you go on about how Access' way is more user 
friendly and robust, blah blah blah...

We've told you what you've asked for can be done. Now it's up to you to 
go try it. There's a free demo on their website. Go download it. If you 
have trouble with certain tasks, we'll be happy to help you here in this 
newsgroup.
0
Kevin
6/29/2004 12:50:04 PM
David W. Fenton wrote:


> 
> Is a "portal" a subform?
> 

Yes. A portal is a subform displaying a related record on a form that 
contains the parent record.


0
Kevin
6/29/2004 12:52:41 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbp726$qjg$7@zcars0v6.ca.nortel.com: 
> 

> And the default?
> 
> If the default is to store the data, then FM is a very stupidly
> designed program. Allowing the storage of the calculated value, but
> not defaulting to it at least puts the blame for the stupidity on
> the developer who chooses to store it. 

Why do you assume that is the default? Do you not understand how 
arrogant and condescending you are?

If you want to know, just ask the question. But yet you assume it is 
what you don't want. Why do you make such assumptions?

Honestly, if you want to learn FileMaker, download the demo and get to 
work. If you don't, then why do you even bother asking the questions? 
It's obvious you don't want to know about it. You just want to be told 
it can't do something so you can continue your sense of superiority.

0
Kevin
6/29/2004 12:55:59 PM
David W. Fenton wrote:


> I did suggest that not supporting the universally used data
> manipulation language of every serious database platform of the last
> 15-20 years doesn't do much to make it look like a serious database
> development platform. 

That would be because you have a very arrogant and misguided view of 
what a "serious" tool is.
0
Kevin
6/29/2004 12:58:43 PM
David W. Fenton wrote:


> Well, it appears you can't use the adjacency method for generating
> nested recursive hierarchies. In any particular application, that
> may not matter (assuming the number of records involved and the
> number of levels does not bog things down), but it is easy to
> imagine applications in which it would be a show-stopper. 
> 

Given that you only seem to understand SQL-based databases, you aren't 
really in a position to say whether or not something is a show stopper. 
At the end of the day, the users want their data. They don't care how it 
is done, as long as it is correct.

But if you want to try to come up with a query that can't be easily done 
in FM, be my guest. Although since you don't seem to understand the 
product that much, it might be a difficult task for you.
0
Kevin
6/29/2004 1:04:02 PM
Michael Diehr wrote:


> 
> It's particularily annoying, given that FileMaker used to be Apple /
> Claris.  You'd think they might still have some connections back at
> Apple to get the SDK...
> 

There's no SDK to get - it is automatic for any app that uses Apple's 
interface widgets. Unfortunately, FileMaker still users their own that 
they developed several years ago - before the advent of scrolly mice.
0
Kevin
6/29/2004 1:06:28 PM
In message <Xns9516B32FC1BEDdfentonbwaynetinvali@24.168.128.86>, David 
W. Fenton <dXXXfenton@bway.net.invalid> writes



>I've not claimed familiarity, so why my lack of it should be held
>against me, I don't know.
>
>I'm trying to learn enough to see if it's worth my while seriously
>trying it out.

I don't think your questions in this newsgroup have really helped find 
that out. Try these instead.

Are you likely to be asked to be asked to write a filemaker application?

Are you likely to need a multi-platform database development 
application? If so, what are the alternatives?

Does filemaker allow data to be validated against business rules before 
committing it to the database?

Can filemaker be used as a front-end for server based databases, such as 
SQL Server, Oracle and MySQL?

Is it possible to build a complex database application in Filemaker?

Note that that last question requires a yes/no answer. Precisely how 
someone would do that isn't really relevant at this stage. If you really 
want to know the details then get hold of a copy, study it then ask 
specific questions in the Filemaker newsgroup. The questions you have 
been asking appear to be off-topic in the Access newsgroup where I have 
been reading them.

[...]
>
>I'm glad you can make a living at it.
>
>I'm sorry you can't see that Access developers are attached to some
>of the techniques we use not because they are what we know, but
>because they make development of user-friendly, robust database
>applications fast and efficient.

They do. But that doesn't preclude other techniques achieving those 
objectives. Until you have used Filemaker you are unlikely to be able to 
ask more useful questions beyond those I have already listed. If you get 
answers, without a copy of Filemaker in front of you it is unlikely that 
you will fully comprehend the answers.

> I'm just trying to figure out if FM
>does things the same way or accomplishes the same tasks in a
>different manner. I'm sorry if I failed to adopt FM terminology, or
>if my questions betray my long-time connections with Access.
>
>I don't really see any way around that problem, so I don't quite get
>why I come under criticism for it.
>
>Tone, well, I have tone problems, yes -- my CDMA colleagues often
>criticize my tone, as well.

I am reading your posts in CDMA and I am certainly critical of your 
tone.

>
>But I don't think there has been anything wrong with the substance
>of my questions, however much I might have been more diplomatic in
>asking them.

That I disagree with. There is little prospect of the questions you ask 
returning any answers that are useful to anyone who wants to compare 
Access and Filemaker, and your tone of voice makes it less likely that 
anyone who knows the answers will bother to supply them.

If you want to ask more questions then try sticking to those that have 
yes/no answers, and that will give you useful information whichever 
answer you get.



-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

0
Bernard
6/29/2004 2:01:05 PM
"K&V P" <random_characters@shaw.ca.invalid> wrote in
news:YT0Ec.929852$oR5.104095@pd7tw3no: 

> "David W. Fenton"  wrote ...
> 
>> And the default?
>>
>> If the default is to store the data, then FM is a very stupidly
>> designed program. Allowing the storage of the calculated value,
>> but not defaulting to it at least puts the blame for the
>> stupidity on the developer who chooses to store it.
> 
> I don't understand why you are so bitter towards Filemaker (or is
> it the whole world?). When someone says it doesn't do something,
> and we say it does and here's how to do it, you say it probably
> does it by default then and must therefore be "a very stupidly
> designed program." 

You don't read very closely.

> What's with that?
> 
> You assume that it will be the way you don't want it.

No, I actually assumed it was designed logically, and would default
to *not* storing derived data. 

> You assume the way you don't want it is stupid.

No, I assumed that it was designed logically. I said that if it
*weren't* designed that way, then it was poorly designed. 

Storing derived data violates the most basic principles of data
normalization and can lead to all sorts of problems in your data,
and, hence, in your application. 

> Virtually every line you type is condescending and/or provocative.
> I don't understand why anyone ever wants to communicate with you,
> except for those of us that enjoy arguing for its own sake.

You don't read very carefully.

> I think your entire contribution can be summed up as "It doesn't
> do what I said I want the way I said I want it to so it's a
> useless piece of shit and I'm sticking my head in the sand now so
> go away" 
> 
> Access is a good tool
> Dbase is a good tool

Was.

> Filemaker is a good tool
> Oracle is a good tool

That does something completely different from any of the other three
mentioned tools. 

> The four have a lot of things in common and some things that are
> different. So don't use Oracle, Filemaker or DBase. I assure you,
> most of us that do will be just as happy with that decision.

We weren't discussing the tools in general.

We were discussing particular features.

And my statement about any stupidity in FM's designed was a
conditional statement, based on an "if" that you seem to have missed
(or chosen to ignore). 

And you won't find many people anywhere who work with databases on
any regular basis who wouldn't also condemn the storage of derived
data as a default configuration. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:02:14 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e16qgsbsp3146@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Field-level validation rules do not replace the BeforeUpdate and
>> AfterUpdate events of controls in Access. 
>> 
>> Not to mention, OnChange, OnEnter, OnExit, MouseOver, MouseDown,
>> MouseUp, KeyDown, KeyUp, KeyPress, GotFocus, LostFocus, OnClick
>> or OnDoubleClick. 
> 
> I don't know how much clearer I can explain it.  I've already
> mentioned the ability to trigger scripts upon exiting a field. 
> But otherwise, there are no true object event control things. 
> Fields aren't commited until the record is committed.  There is no
> OnExit, no Mouse events whatsoever, no keyboard events, focus
> events, etc.  Most of those can be emulated through scripting and
> a plug-in. 
> 
> So -- to summarize this entire discussion: FileMaker can do what
> you want and expect, but it does not do it in the same way you are
> used to. 

I don't see how FM can possibly do the same things when you don't
have the event granularity to control the different parts of the
process. 

With no mouse events, you don't have any options for different kinds
of mouse interactions. I'm not fan of mouseovers myself, but they
are very popular in all sorts of applications, and not having them
available would mean that one common UI convention is not available
to you. 

I could always live without that particular example, but the data
updating events are the ones that bother me. 

Also, as you've explained, validation rules don't happen until the
record is committed, rather than when the field control is updated.
That is a problem, in my opinion, because it means the UI you build
for correcting problems is going to be divorced from the actual
editing process (unless you save the record after every field is
departed, which has its own problems). 

So, yes, it can be done, but it doesn't look like there's much
flexibility in how it can be done, and it looks to me like it forces
a bad UI on the user, where the error-recovery process is separated
from the editing process for each individual field. 

Now, not everyone agrees with me about that -- some people prefer
doing all validation at once and presenting the whole set of errors
for correction at one time. I think that's really a bad method as it
breaks the flow of data entry and requires refocussing attention on
individual fields after a record is submitted. To me, the logical
place to correct an error in a single field is at the time the data
is entered into that field, and from what you've said about FM, I
can't see that this is possible. 

Perhaps you can do it by replicating the validation rules in your
script for the field? Seems rather wasteful of effort, but if that's
the way it can be done, then that's fine (I sometimes duplicate
validation myself, so as to make sure the back end doesn't have to
handle an error, on the theory that it's cheaper to break on an erro
r client-side than it is server-side). 

>> For instance, how in FM can you filter a dropdown list based on
>> user input, and have the dropdown list match your typed choices? 
> 
> You can set up related value lists so that what appears in a list
> is based on a value selected in another field.  This has nothing
> to do with events.  It has to do with how you set up your value
> lists. 

You mean, you have to use multiple controls to make it work?

>> The built-in Access dropdown list by defaults matches as you
>> type, so if you type "m" the first entry beginning with "m" is
>> selected. If you then type "a" you are taken to the first entry
>> beginning with "ma". 
> 
> > In the first case, match as you type, it's a built-in default
> > property of the dropdown list, and a very user-friendly one, at
> > that.
> 
> Same here.

That's good. I've never understood why any dropdown list would be
implemented in any other way. 

>> Now, in cases with dropdown lists that would have very long lists
>> if unfiltered, you might want to populate them only after the
>> user had typed two or three characters. So, you might have them
>> type "ma" then populate the dropdown only with the items starting
>> with "ma." 
>> 
>> In the second case, you can easily implement it in the OnChange
>> event, testing the length of typed-in value and setting the
>> dropdown list's rowsource only after the required number of
>> characters has been typed. 
>> 
>> Can it be done in FM?
> 
> No, this cannot be done in FileMaker because there is no click or
> type event.  It can be emulated, but not very gracefully.  But an
> alternative interface design would be to provide a pop-up window
> with a portal, which is filtered by entries into a global field. 

What if you have multiple such dropdown lists, that would mean a
whole lot of pop-ups. I have had users complaining about too many
pop-ups for a long time. 

> Type as many letters as you want and it will display only the
> records that match what you've typed.  But since fields don't
> update until you've left the field, you have to type what you want
> and then click 'enter'.  Admittedly not as graceful as what you
> have in Access. 

Well, I would implement it that way in Access, myself. Besides, then
the focus would be on the list, anyway, which is where it belongs,
so I don't see that as an issue for FM. 

The main problem here is screen real estate. You could do it without
a popup but it would take a lot of room (I'm assuming a FM layout
can have a portal to more than one table?). And believe it or not, I
have users who are just confused by popups. They fill them out and
then often don't know how to dismiss them, or that they *have* to
dismiss them. I've tried various wordings for the caption of the
command button that closes the popup, but have had no luck in
solving this problem. 

It astonishes me that anyone could use a computer on a regular basis
and not understand a dialog box when confronted with it, but
experience tells me that there are lots of people out there in that
state. 

So, because of those things, I consider using something other than a
dropdown list to be suboptimal UI design. 

However, filtering dropdowns is not something I have to do very
often, in any case, as it's only valuable when the unfiltered
dropdown would have too many choices to be useful. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:19:35 PM
Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
news:10e1798m60c3c77@corp.supernews.com: 

> David W. Fenton wrote:
> 
>> Howard Schlossberg <howard@antispahm.fmprosolutions.com> wrote in
>> news:10e0rlsv778p8c@corp.supernews.com: 
> 
>>>Well, this seems like a petty arguement.  But regardless, a table
>>>has always been a table -- it's just that non-database experts
>>>don't understand that it is called a table.  In prior versions of
>>>FileMaker, there was one table per file.  With Filemaker 7, each
>>>file can have multiple tables.
>> 
>> This particular person with the problem had no difficulties with
>> the terminology. She's a web developer and has actually worked
>> with a number of database-driven websites, so she knows the
>> basics of database terminology. 
>> 
>> But the task, copying data from a calculated field into a new,
>> empty field, was one that a half dozen FM users could not figure
>> out. 
>> 
>> If FM is so user-friendly that people who know nothing about
>> databases can use it, you'd think this handful of non-technical
>> users would be able to figure it out. 
> 
> This discussion is starting to bore me, as well.  Splitting field
> data into multiple fields is simple in FileMaker, given consistant
> data patterns.  And I can't see how it would be any more difficult
> than Access in parsing less consistant data.

To repeat for the 100th or so time:

The user had already SPLIT the field.

She was now having problems with copying the split data into new
fields. 

> If you ask a FileMaker question in an Access forum, then you are
> not really asking knowledged FM users, are you?  I'd imagine that
> if someone asked how to do the same thing in Access, but asked in
> the FileMaker forum, she might have gotten the same sound of
> stupidity.  I don't see how that reflects on FileMaker or its
> users. 

Again, the only question remaining was how to copy one thing from
one field (that happened to be calculated) into a new, empty field.
Those of us who knew SQL could have written a SQL statement in our
sleep to do the job, *if* FM had supported SQL. 

Why do you repeatedly ignore the entire point of my anecdote?

>> If FM did SQL, though, they would have had their answer, and it
>> could have come from an Oracle user, a MySQL developer, a Sybase
>> DBA, an MS SQL Server user or even from a lowly Access developer.
>> As it was, this person was limited to getting useful assistance
>> from people with experince using FM, and, alas (however hard it
>> might be for experienced FM developers to believe), she never
>> seems to have gotten a proper answer. 
> 
> I still haven't seen it asked here in the FM newsgroup.  Do you
> want an answer on her behalf?  Let me know if the HOW is important
> here. 

If the only place to get the answer to such a question is in your FM
newsgroup, then that shows that the lack of SQL support in FM makes
it a harder program to use. 

Which was my point.

And I have no interest in discussing the matter any further, unless
you have something to offer that demonstrates that you've actually
read and understood the situation I was describing, instead of
riffing on some fantasy of yours about what I had said. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:23:19 PM
Kevin Hayes <me@here.com> wrote in
news:cbro5u$era$1@zcars0v6.ca.nortel.com: 

> Solutions to several questions of yours have been provided.

No, what has been provided have been assertions that something can
be done in FM and a very general description of how (e.g., "by using
scripting"). Your copy example is the first actual answer that
provides a real soluton, not just a generalized assertion that
something can be done. 

Perhaps the general descriptions given would be completely clear to
experience FM developers, but you all knew perfectly well that you
weren't talking to people with FM experience. 

And I also find that the devil is in the details -- I can describe a
general approach to solving a problem, but find out when attempting
to implement it that my general approach doesn't actually fully
accomplish everything required in the original problem. 

That's precisely what happened with Howard's answer about the
adjacency problem. He said he could do it with a finite number of
levels in the hierarchy, but the problem as defined was for a
hierarchy with a non-finite number of levels. 

So, the details really *do* matter, and there have been precious
few, if any, offered in this discussion. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:29:26 PM
Kevin Hayes <me@here.com> wrote in
news:cbroo8$fd6$1@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Kevin Hayes <me@here.com> wrote in
>> news:cbp726$qjg$7@zcars0v6.ca.nortel.com: 
>> 
> 
>> And the default?
>> 
>> If the default is to store the data, then FM is a very stupidly
>> designed program. Allowing the storage of the calculated value,
>> but not defaulting to it at least puts the blame for the
>> stupidity on the developer who chooses to store it. 
> 
> Why do you assume that is the default? Do you not understand how 
> arrogant and condescending you are?

You don't read very carefully. I said *IF* the default is to store
the default value. 

> If you want to know, just ask the question. But yet you assume it
> is what you don't want. Why do you make such assumptions?

I stated that if the answer was storing the calculated value by
default then it represented poor design of FM defaults. 

> Honestly, if you want to learn FileMaker. . .

The posts from your newsgroup have dissuaded me from any temptation
to actually try out the FM download (I've repeatedly said I alreay
have the FM7 demo downloaded) -- hardly any of you seem to have any
degree of knowledge that would be adequate to support an Access
developer trying to learn how to use FM. You just don't seem to
understand enough about databases and UI design. 

That's fine -- at one time I didn't either.

But when it's the prime support forum for FM users (as I've been
told repeatedly), it bodes ill for the FM user in need of help,
especially the one coming from a non-FM background. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:32:55 PM
Kevin Hayes <me@here.com> wrote in
news:cbroi2$f4u$2@zcars0v6.ca.nortel.com: 

> David W. Fenton wrote:
> 
>> Is a "portal" a subform?
> 
> Yes. A portal is a subform displaying a related record on a form
> that contains the parent record.

Why, then, would a portal in edit mode need to lock anything in the
parent record except for the fields defining the link between the
parent and child record? 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:33:36 PM
Kevin Hayes <me@here.com> wrote in
news:cbrp7b$fd6$3@zcars0v6.ca.nortel.com: 

> But if you want to try to come up with a query that can't be
> easily done in FM, be my guest. . . .

Er, we've already come up with just that, by your own admission.

> . . . Although since you don't seem to
> understand the product that much, it might be a difficult task for
> you. 

And you people call *me* arrogant?

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:34:51 PM
Bernard Peek <bap@shrdlu.com> wrote in
news:fJ$+A8WhYX4AFwIz@shrdlu.com: 

> If you want to ask more questions then try sticking to those that
> have yes/no answers, and that will give you useful information
> whichever answer you get.

I've gotten lots of Yes/No answers, and then when I probe further
for more than a "YES" I found out that the FM folks have not
understood the question and can't actually outline the specific
steps to solve the problem. 

That's pretty significant, seems to me.

In any event, I have learned enough to decide that I won't waste my
time with the FM 7 demo. 

-- 
David W. Fenton                        http://www.bway.net/~dfenton
dfenton at bway dot net                http://www.bway.net/~dfassoc
0
David
6/29/2004 5:37:26 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbro5u$era$1@zcars0v6.ca.nortel.com: 
> 
> 
>>Solutions to several questions of yours have been provided.
> 
> 
> No, what has been provided have been assertions that something can
> be done in FM and a very general description of how (e.g., "by using
> scripting"). Your copy example is the first actual answer that
> provides a real soluton, not just a generalized assertion that
> something can be done. 
> 

You wouldn't understand the details anyway, so why should we waste our 
time if you aren't really interested in learning?
0
Kevin
6/29/2004 5:53:45 PM
David W. Fenton wrote:


> In any event, I have learned enough to decide that I won't waste my
> time with the FM 7 demo. 

Just as I thought - you weren't interested in learning anything.
0
Kevin
6/29/2004 5:55:29 PM
David W. Fenton wrote:

We were discussing particular features.
> 
> And my statement about any stupidity in FM's designed was a
> conditional statement, based on an "if" that you seem to have missed
> (or chosen to ignore). 

Why bother make the statement at all?
0
Kevin
6/29/2004 5:58:32 PM
David W. Fenton wrote:


> But when it's the prime support forum for FM users (as I've been
> told repeatedly), it bodes ill for the FM user in need of help,
> especially the one coming from a non-FM background. 
> 

We've helped many people that are experienced in Access and other DBs. 
Of course, they didn't come in here with an arrogant attitude assuming 
FM wasn't a serious tool or couldn't do what they wanted. They actually 
tried the tips we gave them and thanked us for them.

0
Kevin
6/29/2004 6:00:28 PM
"David W. Fenton" wrote...
> The posts from your newsgroup have dissuaded me from any temptation
> to actually try out the FM

Well thank God for small favours.

Kent


0
K
6/29/2004 6:14:14 PM
David W. Fenton wrote:

> 
> She was now having problems with copying the split data into new
> fields. 

Where is her data stored now, after she split the data?  You haven't 
provided any details, yet you expect a detailed answer. With the amount 
of data you provided we couldn't give a detailed answer in FM or 
standard SQL.

> Again, the only question remaining was how to copy one thing from
> one field (that happened to be calculated) into a new, empty field.

Loop
  SetField(newField, oldField)
  ...
  GoToNext(ExitAfterLast)
EndLoop


> Those of us who knew SQL could have written a SQL statement in our
> sleep to do the job, *if* FM had supported SQL. 
> 
> Why do you repeatedly ignore the entire point of my anecdote?

Because you have been scant on details. I just gave you a quick answer - 
  I could have given it to you in my sleep.


> 
> If the only place to get the answer to such a question is in your FM
> newsgroup, then that shows that the lack of SQL support in FM makes
> it a harder program to use. 

There you go making arrogant, incorrect assumptions again.

> Which was my point.

Which is irrelevant. We have said help is available. It is. You expected 
a detailed answer but only told us "she has data in one field but wants 
it split into separate fields". We told you how to do it. If you 
actually had FM open, you could open the script editor and easily see 
all the scripts steps available. Or gasp, look in the help files where 
it describes all of the script steps. It's easy. And it helps her learn 
how to do similar things in the future. Handing her an SQL statement 
would only teach her to bug you for another SQL statement for each query 
she wants to make.

> And I have no interest in discussing the matter any further, unless
> you have something to offer that demonstrates that you've actually
> read and understood the situation I was describing, instead of
> riffing on some fantasy of yours about what I had said. 

You: she can't split data in one field into many fields with FM. I only 
know how to do it in SQL
Us: It's easy with the SetField script step (I know I have provided a 
sample script in two posts)
You: You won't tell me how to do it. That is vague and doesn't help FM 
Sucks.
Us: We've told you. Open FM and try it and you'll see.
You: I've decided FM isn't worth wasting my time. I'm through with you. 
FM Sucks. You can't do what I asked for. I have no interest in 
discussing it any further.
0
Kevin
6/29/2004 6:14:18 PM
David W. Fenton wrote:

> Kevin Hayes <me@here.com> wrote in
> news:cbrp7b$fd6$3@zcars0v6.ca.nortel.com: 
> 
> 
>>But if you want to try to come up with a query that can't be
>>easily done in FM, be my guest. . . .
> 
> 
> Er, we've already come up with just that, by your own admission.

Er, the query you provided I could do.

>>. . . Although since you don't seem to
>>understand the product that much, it might be a difficult task for
>>you. 
> 
> 
> And you people call *me* arrogant?

Yes. You aren't willing to try it and keep making incorrect assumption.
0
Kevin
6/29/2004 6:15:21 PM
David W. Fenton wrote:
> Kevin Hayes wrote:
> > David W. Fenton wrote:
> >> 
> >> If the default is to store the data, then FM is a very stupidly
> >> designed program. Allowing the storage of the calculated value,
> >> but not defaulting to it at least puts the blame for the
> >> stupidity on the developer who chooses to store it. 
> > 
> > Why do you assume that is the default? Do you not understand how 
> > arrogant and condescending you are?
> 
> You don't read very carefully. I said *IF* the default is to store
> the default value. 
> 
> > If you want to know, just ask the question. But yet you assume it
> > is what you don't want. Why do you make such assumptions?
> 
> I stated that if the answer was storing the calculated value by
> default then it represented poor design of FM defaults. 

You don't get it, do you? I perfectly understand that the wizardly
knowledgable FM users don't bother talking with you because of your
arrogant attitude. Before asking questions a newbie is expected to
first RTFM and only then ask for something that isn't obviously
covered by the docs or something he doesn't understand. I suggest
you do exactly that if you really want to know about FM which I
somehow doubt.

> > Honestly, if you want to learn FileMaker. . .
> 
> The posts from your newsgroup have dissuaded me from any temptation
> to actually try out the FM download (I've repeatedly said I alreay
> have the FM7 demo downloaded) -- hardly any of you seem to have any
> degree of knowledge that would be adequate to support an Access
> developer trying to learn how to use FM. You just don't seem to
> understand enough about databases and UI design. 

You cannot expect the FM users to explain all the basic principles
to you. A common vocabulary is needed at least. But even then
nobody will want to talk to you because you are such an arrogant
bastard.

I can hardly believe that the c.d.m-a regulars tolerate your
behaviour. Mmh, you've probably made it into their killfiles a long
time ago. Welcome in mine!
0
Lars
6/29/2004 6:17:57 PM
In message <Xns95178AA1DCC67dfentonbwaynetinvali@24.168.128.90>, David 
W. Fenton <dXXXfenton@bway.net.invalid> writes
>Bernard Peek <bap@shrdlu.com> wrote in
>news:fJ$+A8WhYX4AFwIz@shrdlu.com:
>
>> If you want to ask more questions then try sticking to those that
>> have yes/no answers, and that will give you useful information
>> whichever answer you get.
>
>I've gotten lots of Yes/No answers, and then when I probe further
>for more than a "YES" I found out that the FM folks have not
>understood the question and can't actually outline the specific
>steps to solve the problem.

You continue to pose questions based on your knowledge of how Access 
would cope with a situation, expecting the Filemaker users to understand 
what you mean. My suggestion was an oblique way of suggesting that you 
need to spend some more time formulating the questions, in the hope that 
this would enable you to understand what you were asking. The problem 
seems to me that you didn't understand your questions well enough to 
realise that no likely answer would convey any useful information to 
you. However the answers did convey useful information to me, for which 
many thanks.

>
>That's pretty significant, seems to me.
>
>In any event, I have learned enough to decide that I won't waste my
>time with the FM 7 demo.

At the same time I've learned that it could solve some future problems, 
but that I don't require it for any current work. Pretty much all I need 
to know is that some people have written some complex business apps w