Difference favoring 4D or FileMaker?
Phil Stripling
inheriting a DB from a Windows user who set it up in Access. I'm told it's
relational, but I have no clue whether Access really is relational.
On the other hand, I've used MySQL databases from within PHP scripts. Is
there a good graphical interface to MySQL for the Mac that would make
importing the DB and using it within MySQL bearable? Since I don't know
either 4D or FM, that's an option.
On the other other hand, is there a Mac DB that's as dumb as Access? :->
I'd like not to spend big bucks on this.
--
Phil Stripling | email to the replyto address is presumed
The Civilized Explorer | spam and read later. email from this URL
http://www.cieux.com/ | http://www.civex.com/ is read daily.
sbt
<phil_st...@cieux.zzn.com> wrote:
> Are there differences which favor 4D or FileMaker as a database? I'm
> inheriting a DB from a Windows user who set it up in Access. I'm told it's
> relational, but I have no clue whether Access really is relational.
>
> On the other hand, I've used MySQL databases from within PHP scripts. Is
> there a good graphical interface to MySQL for the Mac that would make
> importing the DB and using it within MySQL bearable? Since I don't know
> either 4D or FM, that's an option.
>
> On the other other hand, is there a Mac DB that's as dumb as Access? :->
> I'd like not to spend big bucks on this.
No port from Access is going to be easy. Whether you go with some
frontend to MySQL (there are a lot of them listed at VersionTracker),
use FileMaker, or employ 4D, you're going to have to put a lot of work
into the port.
With that in mind, it really depends upon what features you
need/desire. I've always found forms and report creation to be a royal
pain in the butt using 4D and almost trivial with FMP; however, 4D is
more easily programmed with its Pascalish language than FMP, which
relies on a (rather extensive) scripting language, AppleScript, and
Calculation fields.
Both offer trial versions...check them out.
--
Spenser
Phil Stripling
> relies on a (rather extensive) scripting language, AppleScript, and
> Calculation fields.
I'm mildly comfortable in AppleScript not having looked at Pascal since
back in the 80s some time (remember when Phillippe Kahn was selling Turbo
Pascal?), so that's a plus for FM.
Madwen
> Are there differences which favor 4D or FileMaker as a database? I'm
> inheriting a DB from a Windows user who set it up in Access. I'm told it's
> relational, but I have no clue whether Access really is relational.
>
> On the other hand, I've used MySQL databases from within PHP scripts. Is
> there a good graphical interface to MySQL for the Mac that would make
> importing the DB and using it within MySQL bearable? Since I don't know
> either 4D or FM, that's an option.
>
> On the other other hand, is there a Mac DB that's as dumb as Access? :->
> I'd like not to spend big bucks on this.
I know nothing about Access but I can't imagine that importing it into
any Mac relational DB is going to be anything but a big PITA. Filemaker
is only marginally relational (personally I would never use it for
anything more than a CD collection) and for home/simple use only IMO. I
have used 4D and I doubt you could do much better for a built-for-Mac
DB; however, it has a very steep learning curve and I would not
recommend it unless you have extremely sophisticated needs. The few
people I know who went the way of 4D ended up spending a lot in training
and consulting fees to really nail down their databases. I've been
using Helix RADE for years (my personal preference for legal & research
DBs because of its text flexibility), and though it is close, it is
still not converted to OS X. Agh. Runs great in Classic though. It
does have a very loyal, enduring following but some people don't care
for its unique object language.
Fetch, Rover, Fetch
> Are there differences which favor 4D or FileMaker as a database? I'm
> inheriting a DB from a Windows user who set it up in Access. I'm told it's
> relational, but I have no clue whether Access really is relational.
>
> On the other hand, I've used MySQL databases from within PHP scripts. Is
> there a good graphical interface to MySQL for the Mac that would make
> importing the DB and using it within MySQL bearable? Since I don't know
> either 4D or FM, that's an option.
>
> On the other other hand, is there a Mac DB that's as dumb as Access? :->
> I'd like not to spend big bucks on this.
I use 4D every day -
you give no specifics on what you are trying to get out of the system
(what are you doing?)
if you are tracking email addresses - word is enough
if you are trying to convert a custom accounting app for your larger
business 4D is probably your best bet.
as far as FMP v 4D
the differences are fairly straight forward -
4D is a database engine with an included programing language
FMP - is a scripted database
4D is far more flexible, and far more powerful. This power and
flexibility has a cost - learning curve.
one of the most powerful features is 4D is multi-threaded
it is also compilable, and client server
and updates are so simple -
shut down 4D, replace 'structure' file, restart 4D
Rodger
Madwen <inv...@nospam.com> wrote:
> In article <3qbralu...@shell4.tdl.com>,
> Phil Stripling <phil_st...@cieux.zzn.com> wrote:
>
> > Are there differences which favor 4D or FileMaker as a database? I'm
> > inheriting a DB from a Windows user who set it up in Access. I'm told it's
> > relational, but I have no clue whether Access really is relational.
> >
> > On the other hand, I've used MySQL databases from within PHP scripts. Is
> > there a good graphical interface to MySQL for the Mac that would make
> > importing the DB and using it within MySQL bearable? Since I don't know
> > either 4D or FM, that's an option.
> >
> > On the other other hand, is there a Mac DB that's as dumb as Access? :->
> > I'd like not to spend big bucks on this.
>
> I know nothing about Access but I can't imagine that importing it into
> any Mac relational DB is going to be anything but a big PITA. Filemaker
> is only marginally relational (personally I would never use it for
> anything more than a CD collection) and for home/simple use only IMO.
You must be talking about an older version of FileMaker then. Filemaker
7 is a *very* comprehensive relational DB. I'm using it for a couple
different small businesses.
--
Rodger
Phil Stripling
> Phil Stripling wrote:
> > Are there differences which favor 4D or FileMaker as a database? I'm
> > inheriting a DB from a Windows user who set it up in Access. I'm told it's
> > relational, but I have no clue whether Access really is relational.
>SNIP<
> you give no specifics on what you are trying to get out of the system
> (what are you doing?)
Yeah, that makes it tough to give me any kind of an answer, I know. My
problem is, I'm getting handed a DB from an Access user, and I won't have
it till tomorrow night, and I won't look at it till Friday. I have no clue
what the specifics are, although I know it is a database of club members. I
have seen a variety of reports generated by the DB, but I have no clue
whether any of it is really relational or just straight data with different
sorting employed to pull out more or less data for the various reports.
>
> if you are tracking email addresses - word is enough
Not having Word, I use BBEdit to track email addresses, but that's another
story. :->
>SNIP<
> as far as FMP v 4D
> the differences are fairly straight forward -
> 4D is a database engine with an included programing language
> FMP - is a scripted database
Which I'm sure is meaningful to someone who has used a DB. I equate your
description of 4D with my understanding of MySQL. As for FileMaker being a
scripted database, I'm sorry to say I can't figure that out.
Phil Stripling
> You must be talking about an older version of FileMaker then. Filemaker
> 7 is a *very* comprehensive relational DB. I'm using it for a couple
> different small businesses.
Rodger, do you know if FM can import from Access and not lose any relations
or whatever?
Per Rønne
> Rodger <nob...@forgetit.invalid> writes:
>
> > You must be talking about an older version of FileMaker then. Filemaker
> > 7 is a *very* comprehensive relational DB. I'm using it for a couple
> > different small businesses.
Not comprehensive enough.
> Rodger, do you know if FM can import from Access and not lose any relations
> or whatever?
Just import the tables, including primary and foreign keys. You will
then have to set up the relations between the tables "manually" which is
a little tricky as FileMaker 7 doesn't use the normal way of doing it.
For those of us who are used to ER-diagrams from relational database
theory.
For a start, go into File->Define->Define Database->Relationships. You
make relationships from the master table to the detail table, but you
should double-click on the relation in order to set the options
correctly. Master should have the option "Allow creation of records in
this table via this relationship" and Detail furthermore the option
"Delete related records in this table when a record is deleted in the
other table" set.
Some of the problems with relations between tables {in relation theory:
relations, just to confuse the layman} in FileMaker 7 is the result of
FM's support of many-to-many relations;-(.
--
Per Erik Rønne
Per Rønne
> Are there differences which favor 4D or FileMaker as a database? I'm
> inheriting a DB from a Windows user who set it up in Access. I'm told it's
> relational, but I have no clue whether Access really is relational.
It isn't.
> On the other hand, I've used MySQL databases from within PHP scripts. Is
> there a good graphical interface to MySQL for the Mac that would make
> importing the DB and using it within MySQL bearable? Since I don't know
> either 4D or FM, that's an option.
>
> On the other other hand, is there a Mac DB that's as dumb as Access? :->
> I'd like not to spend big bucks on this.
You can use both MySQl and {the much better} PostgreSQL on your Mac with
MacOS X. I do, however, not have anye experience with proper forms with
them. But you should remember that MacOS X is UNIX. Full Java and full
PHP support.
From a developer's point of view, FileMaker is the easiest database to
handle. But if you have to use more advanced features, you'll have to
turn to 4th Dimension.
If what you want is a simple Contact database with four tables {an entry
table with names and the like, a number table with telephone numbers and
e-mail addresses etc, an address table with addresses and zip codes, and
a post table with zip codes and zip districts - as I have mad for
myself}, FileMaker Pro is fully sufficient, and 4th Dimension would be
overkill.
If, on the other hand, you want to create a kind of accounting system,
you will have to turn to 4th Dimension. FileMaker doesn't support
transactions, 4th Dimension does.
From a user's point of view, it really doesn't matter. After all, it's
the developer's job to make a good interface.
Both 4th Dimension and FileMaker Pro are good database systems, though
not free like the two former.
Import-export? No problems. Just export the tables in tab-separated
files, and remember to convert characters other than 7-bit ascii to
MacRoman.
BTW, Oracle has just released an Enterprise version for MacOS X.
http://www.oracle.com/technology/software/htdocs/devlic.html?http://otn.
oracle.com/software/products/database/oracle10g/htdocs/macsoft.html
--
Per Erik Rønne
Fetch, Rover, Fetch
to something; a button, a field etc.
4D allows the creation of 'project methods' (their terminology) that is
"free floating" code [standard procedures/functions] that can be called
from anywhere else in the program.
FMP - if you want to, say add 2 + 2, and you need to do this in 8 places
you have to write the code in 8 places.
4D (same thing) - you write the code once. then make calls to the
procedure/method from the 8 places.
this all means [in 4D] that if your need to change the code from 2 + 2
to X + Y you change the code once, in one place and it is corrected
(changed) everywhere. in FMP you have to find (or remember) every place
you put the code 2 + 2, then go change it.
Madwen
Rodger <nob...@forgetit.invalid> wrote:
> You must be talking about an older version of FileMaker then. Filemaker
> 7 is a *very* comprehensive relational DB. I'm using it for a couple
> different small businesses.
No, I'm talking about Filemaker. It has improved and is great for
small business accounting and the like but still cannot be reliably used
for something like legal research & case management, medical records
systems, or client/patient intake management systems. For situations in
which you are manipulating vast amounts of data, where you have
databases within databases so to speak, graphical data management,
management of documents external to the database (especially on LANs),
batch posting, globals, and lots of other higher level functions, you
need something of the caliber of 4D or Helix.
Per Rønne
> No, I'm talking about Filemaker. It has improved and is great for
> small business accounting and the like
Without transaction support?
--
Per Erik Rønne
Madwen
sp...@husumtoften.invalid (Per Rønne) wrote:
Well like I said, I personally think it sucks. But for elementary small
business usage, it's great for people who don't know anything about
building databases.
Per Rønne
Personally, I use FM7 for my small Contact base, originally developed
for dBase II on a cp/m-80 computer, and for a few other small databases.
I would never, ever, use it for accounting purposes. Professionally, I'm
most used to Oracle development.
--
Per Erik Rønne, MSc
Frederikssundsvej 308B, 3. tv.
DK-2700 Brønshøj, Denmark
Telephone + fax +45 38 89 00 16, mobile +45 28 23 09 92
J
(=?ISO-8859-1?Q?Per_R=F8nne?=) said:
Also note that Sybase has ASE on the mac. I use both Oracle and
Sybase, and both can handle anything. Not easy and not nice pretty
front end like MSAccess.
--
J
"If there is anything I can do for you or more to the point to you, let
me know."
Per Rønne
> Also note that Sybase has ASE on the mac. I use both Oracle and
> Sybase, and both can handle anything. Not easy and not nice pretty
> front end like MSAccess.
I found it:
http://download.sybase.com/eval/MacOSX/Sybase_ASE_1251_ESD2.dmg
- and will try it.
BTW, I don't think Acces has a "nice pretty front end".
--
Per Erik Rønne
B Collins
J <webs...@fluidic.com> wrote:
> On 2005-02-17 02:20:11 -0500, sp...@husumtoften.invalid
> (=?ISO-8859-1?Q?Per_R=F8nne?=) said:
>
snip
> >
> > If, on the other hand, you want to create a kind of accounting system,
> > you will have to turn to 4th Dimension. FileMaker doesn't support
> > transactions, 4th Dimension does.
Huh? That's funny. . . I could swear I have a full double-entry
accounting system with transactions, accounts and journal entries all
set up and running in Filemaker. I must be suffering from some kind of
illusion.
Bill
snip
--
To send e-mail, remove .invalid
Tom Harrington
B Collins <bbco...@earthlink.net.invalid> wrote:
> > > If, on the other hand, you want to create a kind of accounting system,
> > > you will have to turn to 4th Dimension. FileMaker doesn't support
> > > transactions, 4th Dimension does.
>
> Huh? That's funny. . . I could swear I have a full double-entry
> accounting system with transactions, accounts and journal entries all
> set up and running in Filemaker. I must be suffering from some kind of
> illusion.
For databases, "transaction" has a specific meaning that really has
nothing at all to do with a financial transaction such as you might have
in an accounting system.
--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 2.0: Delocalize, Repair Permissions, lots more.
See http://www.atomicbird.com/
Per Rønne
Are you saying that transactions are a built-in feature in FileMaker
Pro? Or just that someone has built a FM-based system with something
called transactions?
Take a simple three-way transaction. You have sold something which means
that you have to debit a debitor's account. Furthermore you will have to
credit two accounts: a receipts account and a VAT account. What will
happen if the system breaks down in the middle of the transaction.
Remember, the total debits should always be the same as the total
credits. Consequently, in database contexts a transaction is either
fully performed - or not performed at all. It is an /atomic/ action.
--
Per Erik Rønne
B Collins
sp...@husumtoften.invalid (Per Rønne) wrote:
I built a double-entry bookkeeping system in Filemaker Pro. The basic
bookkeeping system has three related files that I named Accounts,
Transactions and Journal. The Accounts are the various asset, liability,
expense and income accounts. Journal stores a debit or credit for each
account. Transaction stores the date and other particulars of the
transaction. Transactions and Journal records are related by transaction
ID. Journal records and accounts are related by Account ID. A portal in
the transaction layout enables creation of related journal records
showing the appropriate account and credit or debit for each. You can
create any number of journal records in one transaction, so you can
allocate different amounts as debits or credits to any number of
different accounts. The system is set up to require that for any
transaction, the sum of debits equals the sum of credits, as in standard
bookkeeping practice. The system also has various other layouts for
reconciling accounts with bank statements, producing a balance sheet and
income statement, etc. None of this is at all outside the standard
capabilities of a Filemaker database. I built this bookkeeping system
myself, first in FileMaker 4, and then migrated to Filemaker Pro 7.
Much more complex business management systems can be built in FileMaker
Pro.
A different poster said something to the effect that "transaction" has a
specific meaning for databases. Fine. The OP to whom I was responding in
my earlier message (quoted above) said that you can't build an
accounting system in FileMaker Pro, which is simply not true.
Bill
Per Rønne
Then, let me quote from the 4th Dimension manual:
Using Transactions
Transactions are a series of related data modifications made to a
database within a process. A transaction is not saved to a database
permanently until the transaction is validated. If a transaction is not
completed, either because it is canceled or because of some outside
event, the modifications are not saved.
During a transaction, all changes made to the database data within a
process are stored locally in a temporary buffer. If the transaction is
accepted with VALIDATE TRANSACTION, the changes are saved permanently.
If the transaction is canceled with CANCEL TRANSACTION, the changes are
not saved.
...
===
START TRANSACTION
Parameter Type Description
This command does not require any parameters
Description
START TRANSACTION starts a transaction in the current process. All
changes to the database are stored temporarily until the transaction is
accepted (validated) or canceled.
If you have several global processes, you can have several transactions.
You cannot, however, nest transactions. If you start a transaction
inside another transaction, 4th Dimension ignores the second
transaction.
See Also
CANCEL TRANSACTION, In transaction, Using Transactions, VALIDATE
TRANSACTION.
===
VALIDATE TRANSACTION
Parameter Type Description
This command does not require any parameters
Description
VALIDATE TRANSACTION accepts the transaction in the current process that
was started with START TRANSACTION. VALIDATE TRANSACTION saves the
changes to the database that occurred during the transaction.
See Also
CANCEL TRANSACTION, In transaction, START TRANSACTION, Using
Transactions.
===
CANCEL TRANSACTION
Parameter Type Description
This command does not require any parameters
Description
CANCEL TRANSACTION cancels the transaction in the current process that
was started with START TRANSACTION. CANCEL TRANSACTION leaves the
database unchanged by canceling the operations executed during the
transaction.
See Also
In transaction, START TRANSACTION, Using Transactions, VALIDATE
TRANSACTION.
===
In transaction Boolean
Parameter
Type
Description
This command does not require any parameters
Function result
Boolean
Returns TRUE if current process is in transaction
Description
The command In transaction returns TRUE if the current process is in a
transaction, otherwise it returns FALSE.
Example
If you perform a multi-record operation (adding, modifying, or deleting
records), you may encounter locked records. In this case, if you have to
maintain data integrity, you must be in transaction so you can
"roll-back" the whole operation and leave the database untouched.
If you perform the operation from within a trigger or from a subroutine
(that can be called while in transaction or not), you can use In
transaction to check whether or not the current process method or the
caller method started a transaction. If a transaction was not started,
you do not even start the operation, because you already know that you
will not be able to roll it back if it fails.
See Also
CANCEL TRANSACTION, START TRANSACTION, Triggers, VALIDATE TRANSACTION.
===
Do you claim that FileMaker Pro 7 has similar capabilities?
--
Per Erik Rønne
Fetch, Rover, Fetch
this means the ability to completely rollback (or confirm) an action.
for example adding an invoice.
you go through the entire process and at the very end the customer says
"...never mind..."
without transactions any inventory adjustments, sequence numbers handed
out etc etc etc may have already been committed, and in a multi user
system undoing this becomes a significant 'trick'
with a transaction NONE of the activities (inventory adjustments etc)
are committed until the transaction is completed (validated), so
canceling is a simple matter and.
B Collins
Murray Watson <JunkD...@adelphia.net> wrote:
> In comp.sys.mac.apps - article <bbcollins-DC1EFC.17520818022005
> @news1.east.earthlink.net>, on Fri, 18 Feb 2005 22:52:08 GMT, B
> Collins says...
> > A different poster said something to the effect that "transaction" has a
> > specific meaning for databases. Fine. The OP to whom I was responding in
> > my earlier message (quoted above) said that you can't build an
> > accounting system in FileMaker Pro, which is simply not true.
> >
> > Bill
>
> You can indeed build an accounting system in virtually any
> database/language regardless of whether low level transaction control
> is provided by the database/language. If on the other hand, you want
> a trustworthy accounting system and the database/language does not
> provide transaction controls, you must provide and promote database
> auditing mechanisms. Something along the lines of storing the
> balances of each transaction participant table within the transaction
> record itself and an auditing program should be run from time to time
> to verify each table received the effect of the transactions relative
> to them.
>
> It's not difficult to do, I've done it, but to have a "trustworthy"
> system, you need database level transaction control and/or accounting
> program provided auditing mechanisms to insure that a "transaction"
> didn't fail in the middle.
>
> An example of program logic would be to include a field for example
> called "InTransaction", and if you want to make life easier, include
> a field "TransactionID".
>
> 1) Before beginning an accounting transaction, set the
> "InTransaction" field in all participant table records and
> (FLUSH/SYNC) initiate whatever is available to insure those records
> are written to disk.
>
> 2) Write your transaction table record and set the transaction ID in
> all the participant table records, FLUSH/SYNC all that to disk.
>
> 3) After the above sequence, clear the InTransaction and
> TransactionID fields from each respective transaction participant
> table and FLUSH/SYNC.
>
> 4) A mechanism should be put into place to examine the InTransaction
> and TransactionID fields upon every read, reporting the existence of
> this condition to the user as an error. This will help bring a
> failed traction to light as early as possible to prevent further mis
> calculations. A monthly data audit should be performed to inspect
> all records of transaction participant tables looking for the status
> of the "transaction" fields and reporting the existence of any.
> Since you're examining all records, it's a good time to make sure
> things crossfoot.
>
> Given the current state of reliability of OSX or Win??, using a
> database engine providing transaction control or manually programming
> the equivalent into your application is prudent and professional.
>
> If you're monitoring other's money via your program or distributing
> your program, you have a fiduciary responsibility to provide one or
> the other of database provided transaction controls or a programmatic
> equivalent.
Thank you. You have added to my education about databases.
I think I have made my FileMaker accounting system in such a way that it
is easy to verify that a transaction is correct on entry, and easy to
audit after the fact. This is without having the facilities for database
transaction control that you describe.
When I create a bookkeeping transaction (which, as you point out, is not
the same as a database transaction), the layout shows the fields for the
transaction (date, description, etc) and a portal to the related Journal
table. I create the Journal records right in the portal. Each journal
record shows the account and the debit or credit amount posted. Thus I
see the journal records directly as they are created. Below the portal
are fields that display the sums of the debits and credits from the
related Journal records, and a field that displays a warning if the sum
of the debits does not equal the sum of the credits.
Each of my transaction records is automatically assigned a transaction
ID when it is created. This is a serial number, and is required by field
validation to be unique. The Journal records created within that
transaction are automatically assigned that transaction ID, as well as
their own unique serial number ID. The journal records are related to
the transaction by the Transaction ID.
A second level of audit is provided in a layout for each account. That
layout shows fields that describe the account (name, type, etc), and a
portal that shows the journal records related to that account. The
journal fields displayed include date & description (taken from the
related Transaction record), Debit and Credit fields, and fields for
marking reconciliation with a bank statement, credit card statement,
etc. Below the portal are fields that show the sum of the debits and
credits, as well as the sum of debits and credits that are marked as
reconciled with the bank statement. this provides an easy and reliable
way to verify the accounting against bank statements and the like.
Each of my account records is automatically assigned a unique serial
number Account ID when it is created. When I create a Journal record
within a transaction, and then select the account to post to, that
Account ID is automatically entered in an Account ID field in the
Journal record. The Journal record is thereafter related to the account
by the Account ID.
The system is set up also to generate a balance sheet and an income
statement. This provides another level of checking for accuracy.
It is also set up to generate a Detail Trial Balance for each account,
which prints all the Journal records associated with that account, with
appropriate summary calculations.
FileMaker does have a feature called committing the record. This does
not exactly match what you describe as transaction control, but it does
assure that the record is indeed entered into the database.
Thanks again for your information and advice. I think I have a pretty
sound bookkeeping system using FileMaker.
Fetch, Rover, Fetch
> Thank you. You have added to my education about databases.
>
> I think I have made my FileMaker accounting system in such a way that it
> is easy to verify that a transaction is correct on entry, and easy to
> audit after the fact. This is without having the facilities for database
> transaction control that you describe.
>
> When I create a bookkeeping transaction (which, as you point out, is not
> the same as a database transaction), the layout shows the fields for the
> transaction (date, description, etc) and a portal to the related Journal
> table. I create the Journal records right in the portal. Each journal
> record shows the account and the debit or credit amount posted. Thus I
> see the journal records directly as they are created. Below the portal
> are fields that display the sums of the debits and credits from the
> related Journal records, and a field that displays a warning if the sum
> of the debits does not equal the sum of the credits.
without a transaction (database) what happens when the power goes down
on a client or server (or crash of either) occurs?
you will likely end up with partial transactions (accounting)
also what about locked records during your accounting transactions
ie 2 people trying to enter/sell/buy/credit/debit the same account/item?
Rodger
Murray Watson <JunkD...@adelphia.net> wrote:
> I suspect that is what I refer to as FLUSH/SYNC, forces a write to
> the disk otherwise things get cached in memory for performance.
No, they are two different things. Committing the record assures tht
the record is indeed entered into the database. Flush forces a write to
the disk.
--
Rodger
Tom Harrington
Michael Vilain <vil...@spamcop.net> wrote:
> I don't think it was intended to ever replace a transaction-based DBMS
> like Sybase or Oracle. There are other databases out there now that run
> on MacOS X, but 4D is the only one that uses transactions with a
> client/server model.
...except for things like Postgres. And doesn't MySQL do transactions
these days?
> My guess is if you want the safety of transactions, stored procedures,
> and a real DBMS capable of handling large volumes of data (1M+ rows),
> you _could_ go to Postgres on a MacOS Xserver with a tape backup system.
> Or run the same thing on Linux on a X86 box. Or spring for Oracle.
...but then I guess you knew that...
B Collins
> In article <MPG.1c83bfffa...@news1.news.adelphia.net>,
> Murray Watson <JunkD...@adelphia.net> wrote:
>
> > In comp.sys.mac.apps - article <mUcSd.47643$i42.7033
> > @fe1.columbus.rr.com>, on Mon, 21 Feb 2005 03:50:42 GMT, Rodger
> > says...
> > Hmm, Filemaker certainly seems out of sync with the terminology the
> > rest of the DB world relies on.
> >
> > The rest of the DB world simply uses "write" and "commit" is reserved
> > for transaction processing. Most if not all commercial DBs have
> > mechanisms to force their buffers to be written to the OS and send a
> > semaphore to the OS forcing the cache to be written to disk,
> > typically called FLUSH which long ago before DBs used caching,
> > relying on OS optimized caching instead, used to be a simple call to
> > the Unix command SYNC which forced the OS to write all it's buffers
> > to disk.
> >
> > I purchased a copy of FM pro a couple of years ago 2001-2002? for a
> > Mac oriented client to use to access an Oracle system I was writing,
> > there was some sort of problem, it's inability to connect via ODBC or
> > something rudimentary and I simply threw it away, I found it lacking
> > in many areas and not worth pursuing, but that was in a Windows
> > environment. Options in the Mac world are more limited.
> >
> > That client was running 4D client/server, on an NT Server when I
> > arrived and it's capabilities were quite robust but we were looking
> > for something that could grow into a 10-20 processor scale system, I
> > don't know if they have a single user/desktop version priced in the
> > Filemaker range or not.
>
> Well, if you look at historically where 4D and Filemaker came from, it
> sort of makes sense. Filemaker 3 was Claris' database offering,
> essentially a flat-file, GUI-driven, single-user information manager.
> The Names Quilt used it to store their quilt-maker's database and was
> overjoyed when Claris updated it to store more than 32K records.
>
> I don't think it was intended to ever replace a transaction-based DBMS
> like Sybase or Oracle. There are other databases out there now that run
> on MacOS X, but 4D is the only one that uses transactions with a
> client/server model.
>
> My guess is if you want the safety of transactions, stored procedures,
> and a real DBMS capable of handling large volumes of data (1M+ rows),
> you _could_ go to Postgres on a MacOS Xserver with a tape backup system.
> Or run the same thing on Linux on a X86 box. Or spring for Oracle.
>
> Both can run on a Windows and MacOS, which was news to me. I thought 4D
> was pretty much a Mac-only application.
I do not mean to suggest that anyone who is using 4D or some other
capable database manager that they are happy with should switch to
FileMaker.
I will simply say that FileMaker has advanced very considerably in the
last few years, and can handle very large relational multi-user
databases quite reliably. It is also very easy to learn to use. Many of
the limitations you mention from the older versions no longer apply.
For example, FileMaker Pro 7 allows up to 8 terabytes per file and up to
a million tables per file (yes, FMP 7 can have multiple tables per file,
which earlier versions could not). Individual text and container fields
can store gigabytes of information. FileMaker 7 can communicate and
exchange data with applications that use XML, ODBC and JDBC.
FileMaker Server can host up to 125 files. Hosting by FileMaker Pro is
more limited.
I am not an expert on other database managers, so please excuse my
ignorance. From reading this thread, I have the impression that some of
the concerns about transaction-level control are actually handled by the
way the FileMaker user interface works. I may be mistaken about this,
but I do not find the kind of lack of security and reliability that you
mention.
FileMaker has become very capable and solid. I think that it is not
appropriate to criticize it based on short acquaintance with an early
version.
If you have not looked at FileMaker for a while, perhaps you should. You
might be pleasantly surprised. You can get more info at the FileMaker
web site http://www.filemaker.com if you wish.
Tom Harrington
Michael Vilain <vil...@spamcop.net> wrote:
> In article <tph-1366A5.15175821022005@localhost>,
> Tom Harrington <t...@pcisys.no.spam.dammit.net> wrote:
>
> > In article <vilain-A6ACF3....@comcast.dca.giganews.com>,
> > Michael Vilain <vil...@spamcop.net> wrote:
> >
> > > I don't think it was intended to ever replace a transaction-based DBMS
> > > like Sybase or Oracle. There are other databases out there now that run
> > > on MacOS X, but 4D is the only one that uses transactions with a
> > > client/server model.
> >
> > ...except for things like Postgres. And doesn't MySQL do transactions
> > these days?
>
> MySQL 5 was supposed to have stored procedures but I haven't heard if
> transactions are on the feature list. It's still in beta, isn't it?
At <http://www.mysql.com/products/mysql/> they claim the current version
(4.1) has transactions, if you use the right table type. I haven't put
it to the test myself.
I see 4.1 is also supposed to support foreign keys, which I didn't
realize. I may have to migrate my Postgres DB to MySQL. I chose
Postgres to get transactions and foreign keys, which weren't available
in MySQL at the time. But I ended up running MySQL anyway for some
other tools that required it (and to have a local mirror of my hosting
company's setup). It'd be nice to lose the need to run two DBs on the
same Powerbook.
Per Rønne
> In article <vilain-A6ACF3....@comcast.dca.giganews.com>,
> Michael Vilain <vil...@spamcop.net> wrote:
>
> > I don't think it was intended to ever replace a transaction-based DBMS
> > like Sybase or Oracle. There are other databases out there now that run
> > on MacOS X, but 4D is the only one that uses transactions with a
> > client/server model.
>
> ...except for things like Postgres.
Oracle Corporation /has/ come with a MacOS X version of Oracle
Enterprise Edition.
http://www.oracle.com/technology/software/products/database/oracle10g/in
dex.html
It does, however, demand MacOS X 10.3 Server.
--
Per Erik Rønne
Tom Harrington
sp...@husumtoften.invalid (Per Rønne) wrote:
The "things like" part was intended to be sufficiently broad to cover
more than just Postgres, without going to the trouble of tracking down
every possible choice along those lines.
Per Rønne
> In article <1gsou5x.5czkpn1qyyxmuN%sp...@husumtoften.invalid>,
> sp...@husumtoften.invalid (Per Rønne) wrote:
> > Tom Harrington <t...@pcisys.no.spam.dammit.net> wrote:
> > > In article <vilain-A6ACF3....@comcast.dca.giganews.com>,
> > > Michael Vilain <vil...@spamcop.net> wrote:
> > > > I don't think it was intended to ever replace a transaction-based DBMS
> > > > like Sybase or Oracle. There are other databases out there now that run
> > > > on MacOS X, but 4D is the only one that uses transactions with a
> > > > client/server model.
> > > ...except for things like Postgres.
> > Oracle Corporation /has/ come with a MacOS X version of Oracle
> > Enterprise Edition.
> > http://www.oracle.com/technology/software/products/database/oracle10g/in
> > dex.html
> > It does, however, demand MacOS X 10.3 Server.
> The "things like" part was intended to be sufficiently broad to cover
> more than just Postgres, without going to the trouble of tracking down
> every possible choice along those lines.
I should think that Oracle {the world's number one relational database}
is more than "things like". But of course, I've got years of experience
as a professional Oracle developer.
--
Per Erik Rønne
Tom Harrington
sp...@husumtoften.invalid (Per Rønne) wrote:
OK, maybe I should just drop it, but what _would_ you consider to fall
under "things like" Postgres, if not Oracle? I guess MySQL falls into
that group. What else, and why not Oracle? It's an industrial strength
SQL-based database, and so is Postgres.
Per Rønne
> In article <1gspot7.gonoskye8scrN%sp...@husumtoften.invalid>,
> sp...@husumtoften.invalid (Per Rønne) wrote:
>
> > Tom Harrington <t...@pcisys.no.spam.dammit.net> wrote:
> >
> > > In article <1gsou5x.5czkpn1qyyxmuN%sp...@husumtoften.invalid>,
> > > sp...@husumtoften.invalid (Per Rønne) wrote:
> > > The "things like" part was intended to be sufficiently broad to cover
> > > more than just Postgres, without going to the trouble of tracking down
> > > every possible choice along those lines.
> > I should think that Oracle {the world's number one relational database}
> > is more than "things like". But of course, I've got years of experience
> > as a professional Oracle developer.
> OK, maybe I should just drop it, but what _would_ you consider to fall
> under "things like" Postgres, if not Oracle? I guess MySQL falls into
> that group. What else, and why not Oracle? It's an industrial strength
> SQL-based database, and so is Postgres.
I wouldn't say that Postgres is an industrial strength database. It's a
good freeware kernel with a user interface, psql, which is similar to
Oracle's sqlplus, but it has never had a tool as strong as SQL*Forms and
successor Oracle Designer/Developer. And although sqlplus is a must for
developers, sqlforms is a must for end-users - and much of the
developing process is on making these cross-platform forms.
--
Per Erik Rønne
Per Rønne
> One may want to reconsider the boldness of a statement like "world's
> number one", while true today in the 'Nix arena, DB2 and SQL Server
> are gobbling up previously held Oracle turf in large bites with
> distinctively different market shares for 'Nix vs. Win platforms.
>
> Much of what made Oracle appealing is simply not a distinctive factor
> anymore. I'm not saying they aren't useful in specific situations.
> Raid boxes and Network storage obsoleted much of Oracle's tunability.
> If you're require large scale and may migrate to various platforms,
> Oracle is still top dog but if you're in the 90% of the marketplace
> that don't, DB2 or SQL Server is easier to maintain. HOWEVER, being
> an PLSQL guy myself, an Oracle backend fronted by Oracle
> Designer/Developer is a hard combination to beat.
I'd say that these features are a must. But when I have been developing
in Oracle it has been as an IBM consultant in large Danish entities like
Copenhagen Airport, or for the State of Denmark which almost entirely
uses Oracle {though most of the clerks think it is Access:-)}.
But of course, national registers and a common administration system for
all Danish universities /do/ have special needs. BTW, only public
universities are allowed in Denmark, private schools that call
themselves "universities" aren't allowed to give their graduates the
Danish academic titles - titles which are protected by law. My own
academic title, /candidatus scientiarum/ in computer science {six years
after the A-levels}, similar to English MSc is thus protected, and
anyone who unrightly uses the title may get punished.
--
Per Erik Rønne
Scott Ellsworth
sp...@husumtoften.invalid (Per Rønne) wrote:
Interesting. One of my clients has terabytes of genetic sequence data
and their scientific research results concerning it. All stored in
Oracle, and accessed via SQLPlus, Access, and a whole passel of
different custom Java and .NET applications.
They could do everything they are doing now with postgres, mysql,
SqlServer, etc., but they find Oracle has better uptime.
It is not a lack of sqlforms that makes them stay, but reliability and
the impact of the bugs they have found. From their perspective, the
other options do compete quite successfully, and they find them
"industrial strength".
Scott
Per Rønne
> > I wouldn't say that Postgres is an industrial strength database. It's a
> > good freeware kernel with a user interface, psql, which is similar to
> > Oracle's sqlplus, but it has never had a tool as strong as SQL*Forms and
> > successor Oracle Designer/Developer. And although sqlplus is a must for
> > developers, sqlforms is a must for end-users - and much of the
> > developing process is on making these cross-platform forms.
>
> Interesting. One of my clients has terabytes of genetic sequence data
> and their scientific research results concerning it. All stored in
> Oracle, and accessed via SQLPlus, Access, and a whole passel of
> different custom Java and .NET applications.
>
> They could do everything they are doing now with postgres, mysql,
> SqlServer, etc., but they find Oracle has better uptime.
>
> It is not a lack of sqlforms that makes them stay, but reliability and
> the impact of the bugs they have found. From their perspective, the
> other options do compete quite successfully, and they find them
> "industrial strength".
OK, but in Denmark I have never really found software houses that
developed for PostgreSQL. But lot that develop for the Oracle platform.
And, btw, I do consider a kind of forms developing tool a must in
databases. Users simply can't be supposed to use SQL*Plus or psql for
ordinary tasks like inserts or look-up. It is a developer's tool, and a
tool for people with special needs - like people who need special
information from the database. You can't expect a clerk to use SQL
directly, but you can expect a statistician to do so.
--
Per Erik Rønne
Fetch, Rover, Fetch
Verne Arase
(in article <3qbralu...@shell4.tdl.com>):
> Are there differences which favor 4D or FileMaker as a database? I'm
> inheriting a DB from a Windows user who set it up in Access. I'm told it's
> relational, but I have no clue whether Access really is relational.
>
> On the other hand, I've used MySQL databases from within PHP scripts. Is
> there a good graphical interface to MySQL for the Mac that would make
> importing the DB and using it within MySQL bearable? Since I don't know
> either 4D or FM, that's an option.
>
> On the other hand, is there a Mac DB that's as dumb as Access? :->
> I'd like not to spend big bucks on this.
Betcha you're sorry you asked.
I just converted (in half an hour or so) a printed reports database that
someone sent me in Access form. I exported the tables in DBASE form and
imported 'em into FileMaker no problem. I suspect that if I worked at it (a
lot) I might have gotten the forms, but they I was principally concerned with
the data and that's what I got.
I think what you're getting in the newsgroup is a collection of DBAs with
auditors hot on their tails anxious to pound them a new orifice should an
incomplete transactions get posted to their database. I don't know if your
information is that critical, but my suspicion is that it is not (or it
wouldn't have been done in Access in the first place).
I'm not a Filemaker developer - just someone who wants to organize data in a
form less cumbersome than Excel. My databases are all small (largest so far
is about 60k records), and any relational needs I have are pretty mundane. I
used to use Panorama (which I don't believe was truly relational), but their
licensing and protection drove me nuts and I went to Filemaker just to leave
their paranoia behind.
Filemaker has its glitches: sometimes some of my related fields get exported
weirdly (if I forget an option), and sometimes the insertion point in a data
entry field gets lost so it's not really pointing where it ought to, but for
the most part Filemaker Pro v7 is pretty solid.
What it is humanly understandable, and relatively easy for this Mac user to
figure out - which, incidently, Access was not (particularly with the
prodigious documentation distributed with a full install of MS Office).
Anyway, I think what you ought to do is let folks know what your situation
is, and where you're coming from so that can help filter your replies.
Is this a mission critical database?
What are you priorities? Do you just want to get something that mostly works
for a minimum of effort, or are you a DBA trying to find a product which will
allow you to produce synchronized backups with audit trials?
It's your thread, but before you can get the information you desire you have
to limit the scope of what you're asking for.