Filemaker vs Alpha

[G Gabriel]

Good morning.

When it comes to Filemaker, I am not even a beginer, I am for the lack of a better word, totally ignorant.

I just registered at this forum and when you register you have to answer certain questions as to what version you use etc. Since there was no option for "none", I put the lowest version. Please disregard that. I don't even have Filemaker. Never did.

The purpose of my thread is two folds:

1-How does Filemaker compare with alpha?

2-I am a long time user of alpha. I have recently designed a development module that solves many of the most daunting problems with alpha. I had a feeling that the same problems are common to both programs. I was about to download the Filemaker free trial to examine and see for myself but thought it might be better to ask those who had more experience with it.

So, my second question entails: do you run into problems, particulary if you are on a network, with tables being in use, tables that did not close, records locked by other session? etc.

If so, my working module might resolve these issues in Filemaker as well and might make it worthwhile to dig deep into filemaker.

Thank you.

[Zero Tolerence]

Never used alpha, so can't help you there.

But, as far as the problems you mentioned, no, I don't think FM has any of them. Records being locked happens, but only if someone else is currently in said record, and frankly, thats a good thing.

[G Gabriel]

Thanks for the reply.

How does FM optomize network multi-user enviroment?

Shadow tables?

[Genx]

What exactly is a Shadow Table?

[mr_vodka]

Perhaps we should ask Shawn. hehe... since "the shadow knows"... I couldnt help myself.

Ok enough with the corny jokes. :

Shadow Table Link 1

Shadow Table Link 2

[Genx]

Lol, that was corny, even for you :

Thanks for the links John.

[The Shadow]

Okay, I'll bite. :

The FM client program caches records that have been accessed locally. Unlike most databases, FM server notifies clients when records have changed, so they can clear there local cache of the stale data.

For writing, the record(s) being changed are locked on the host, and the changes are written thru the local cache to the host on commit.

Finds (queries) are sent up to the server which responds with a list of record ids that match the query. Any data needed (to view the result) is requested by the client in a seperate operation.

FileMaker hosts expect occasional keep alive messages from an idle client or they will disconnect the client and free any outstanding locks that client was holding.

I hope that answers your question.

Shawn

[G Gabriel]

Thanks Shawn for the clarification. What you have described is in every sense of the word a shadow DB.

I am still unclear about one issue.

If you are on a network, FM will cache all records that have been opened by the local machine then notify the local user if records have been changed.

Question: Does FM issue this notification each and every time a change was made? or does it compare the local records in the local machine with those on the server and issue the notification if they are different?

And if FM makes periodic comparisons, then how often?

Thanks again.

[The Shadow]

The server doesn't send the new data to all clients, it sends out lists of record ids that have been changed/added/deleted. The clients then delete them from their local cache, which may result in them requesting the new record contents if they needed it.

This basically occurs for every commit, but the server will batch up multiple messages if it can.