Johannes,
We have all our primary and secondary source material (microfilms,
books, new and old editions, etc.) in several File Maker Pro
databases (running on Macs), which can be searched for as many
criteria as you choose to enter originally (composer, performing
forces, performance
Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on
a Mac? I want something which is easy to maintain and where I can see
how many string parts we have, perhaps also who
David W. Fenton wrote:
On 18 Aug 2008 at 15:54, dhbailey wrote:
Maybe that's why the name is Drum Corps International and
not Drum and Bugle Corps International anymore -- all it
is in reality is simply a brass band pitched in G, where all
the instruments are of the horn family and none from
I currently have a Mac Powerbook G4
running OS 10.3.9 (I need to be able to continue to run Finale 2003a
on Classic), and so I'm planning on purchasing a new iMac so I can run
a newer version of Finale.
How do I transfer all of my files, including folders, bookmarks on
Safari, my emails (I use
On 19.08.2008 mystrom1 wrote:
How do I transfer all of my files, including folders, bookmarks on
Safari, my emails (I use Mac mail) plus other settings? I've been told
I need a firewire cable from one mac to the other, but I've also been
told that once I turn on a new iMac, it will search,
It's pretty simple, actually. When you run your new Mac the firs time it will
ask you whether you want to copy data from another Mac, and if your answer is
YES, then it will guide you through the steps on how to connect the two
machines. Then it will copy the User data from the old to the new.
i am using filemaker, some of the terms may be specific to it...
if you spend the time in the beginning you will save loads of time
rebuilding / restructuring the thing later. keep it simple, but each
type of data should have its own field. do not build multiple DBs,
keep all the
On Aug 19, 2008, at 7:31 AM, Johannes Gebauer wrote:
On 19.08.2008 mystrom1 wrote:
How do I transfer all of my files, including folders, bookmarks on
Safari, my emails (I use Mac mail) plus other settings? I've been
told
I need a firewire cable from one mac to the other, but I've also been
I currently am using Finale 2003a, which I know won't run on Leopard.
I am planning on installing a 2008 on my new computer, so I don't
think this will be an issue for me. I hope. I am hoping that this
process will automatically transfer my settings for my email, my
bookmarks on safari, and my
--- dhbailey [EMAIL PROTECTED]
wrote:
I can't recommend a program for Mac, but it can be
done with
either a spreadsheet or a database. Either program
should
give you the ability to look at the data in
different ways.
Microsoft Office is available for Mac - I'm using
Excel for my
John Howell gave you lots of good advice. My experience has been as
well that drum arrangers guard their secrets and scores like the Holy
Grail. All field drummers play by memory. Some styles are complex
(like American drum corps; they typically spend the whole year
learning an 11-minute
duh. obviously the contact info goes in the composer table.
in the works table, for example:
composition_title
composed_in
composer_ID
fl_scored
ob_scored
cl_scored
[...]
fl_parts
ob_parts
cl_parts
address
city
province
country
in the composer table:
family_name (avoid using last_name, can
I highly recommend Bento--It's made by the file maker folks, it's
inexpensive, and really easy to use.
http://www.filemaker.com/products/bento/overview.html
On Aug 19, 2008, at 12:38 AM, Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing
music
You know, it would be wiser to aggregate the data even more.
Rather than having the works table have fl_scored, cl_scored, etc, have a
scored_id and another table that that links to.
scored
id, instrument_id
instruments
id, name
Sorry, did Oracle DBA for 2 years for a startup right out of
Hello all,
I've encountered a strange problem with courtesy time signatures --
I've been working on a score with frequently changing time signatures,
and have display courtesy time signatures at end of system turned on
as always. For a while it was showing them, but recently they have
A relational database probably is not the best thing to use for doing this
sort of thing. Unless you want to mine your library for stuff, or have
thousands and thousands of things in there
I'd say set up some sort of card system. That would the easiest thing to do.
On Tue, Aug 19, 2008 at 3:02
Access is not available for the MAC unless you run VMware or Parallels.
Steve
8/19/08 8:02 AM, Lora Crighton [EMAIL PROTECTED] wrote:
--- dhbailey [EMAIL PROTECTED]
wrote:
I can't recommend a program for Mac, but it can be
done with
either a spreadsheet or a database. Either
I'd like to add my vote for FileMaker Pro. I'm a choral director and find it
to be very flexible, easy to use and able to do just about anything I can
dream up.
One of the keys is what several have already mentioned about planning what
info you need and how you're going to be using and entering
On Aug 19, 2008, at 4:08 AM, mystrom1 wrote:
I currently have a Mac Powerbook G4
running OS 10.3.9 (I need to be able to continue to run Finale 2003a
on Classic), and so I'm planning on purchasing a new iMac so I can run
a newer version of Finale.
The utilities that come with the Mac do work
copy the data to a new file if you can. it sounds (possibly) similar
to something i had where time sigs were faded to about 50% grey and i
was never able to print some of them, the file seemed to have been
corrupted. the finale techs were not able to find out the reason, as
far as i know.
Agreed on all points. One thing, though: It would certainly be
possible to have fields for who has each part checked out, but
remember that every datum has to be entered and that this will take
your librarian quite a while. There are times when a simple paper
signout sheet is still
I'd like to add one more thought to the plan well before
starting idea --
Once you have it planned out, enter only 5 or 10 works, with
all the data as you have it planned out, then run some
typical queries on it to see if it will give you the
information you want.
There's nothing worse
On 19 Aug 2008 at 7:38, Johannes Gebauer wrote:
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on
a Mac? I want something which is easy to maintain and where I can see
how many string parts we
On 19 Aug 2008 at 9:02, Lora Crighton wrote:
Microsoft Office is available for Mac - I'm using
Excel for my church choir library. The spreadsheet
does have limited database functions,
Excel is really terrible for database needs. It is great for what
it's intended for, but if you really need
On 19 Aug 2008 at 7:35, Eric Dannewitz wrote:
A relational database probably is not the best thing to use for doing this
sort of thing. Unless you want to mine your library for stuff, or have
thousands and thousands of things in there
I'd say set up some sort of card system. That would the
My orchestra needs to create a database for its small, but growing
music library. Can someone give me some hints on how to do this,
preferable on a Mac? I want something which is easy to maintain and
where I can see how many string parts we have, perhaps also who
borrows which part, etc.
Basically, unless you are going to be cataloging thousands if pieces,
or are interested in strange queries of your data, you don't need a
relational database
On Aug 19, 2008, at 2:08 PM,n David W. Fenton [EMAIL PROTECTED]
wrote:
On 19 Aug 2008 at 7:35, Eric Dannewitz wrote:
A
On 19 Aug 2008 at 14:20, Eric Dannewitz wrote:
Basically, unless you are going to be cataloging thousands if pieces,
or are interested in strange queries of your data, you don't need a
relational database
This is what many people believe. I make a large portion of my income
fixing the
Eric Dannewitz wrote:
Basically, unless you are going to be cataloging thousands if pieces, or
are interested in strange queries of your data, you don't need a
relational database
But if you also want to be able to put together information
on the composers, you'd have the composer
On 19 Aug 2008 at 18:04, dhbailey wrote:
Eric Dannewitz wrote:
Basically, unless you are going to be cataloging thousands if pieces, or
are interested in strange queries of your data, you don't need a
relational database
But if you also want to be able to put together information
on
Basically, unless you are going to be cataloging thousands if pieces,
or are interested in strange queries of your data, you don't need a
relational database
This is what many people believe. I make a large
portion of my income fixing the results of that
belief.
i would v-e-r-y
I think Filemaker actually will try to complete the field as you type it.
So, if you are Typing Amadeus it will complete it before you do.
A small database of like 1000 pieces can easily be done flat file, and
really doesn't warrant a huge relational structure, especially when the
person who is
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters needs.
On Tue, Aug 19, 2008 at 3:28 PM, shirling
Eric Dannewitz wrote:
[snip]
On the flip side, a relational database is very easily messed up. You delete
the foreign key to the composers table that was linking song titles to their
composers. Not easy at all to fix. And a lot of people who have no database
experience can very easily do this.
Point is that the original poster is not a database worker. And has no plans
on having tens of thousands of things in the database. Therefore, using a
flat file database, like Bento, or even index cards, would be totally fine
to use. They really don't need to learn how to set up and manage a
I think Filemaker actually will try to complete the field as you
type it. So, if you are Typing Amadeus it will complete it before
you do.
nope. but value lists come close to this.
A small database of like 1000 pieces can easily be done flat file,
and really doesn't warrant a huge
On 19 Aug 2008 at 16:18, Eric Dannewitz wrote:
I think Filemaker actually will try to complete the field as you type it.
So, if you are Typing Amadeus it will complete it before you do.
But that's not by any means the same thing as enforcing correct
entry. For instance, if somebody mis-types
On 19 Aug 2008 at 16:21, Eric Dannewitz wrote:
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters
Geeze, go back and read the ORIGINAL POST
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on a
Mac? I want something which is easy to maintain and where I can see how many
string parts we have, perhaps
I give up. Fine. Get the guy a relational database. Hell, get him an Oracle
one. Might as well get the best right? Who knows how many times he'll need
to run queries on how many string parts a Mozart concerts from XYZ edition
have..
On Tue, Aug 19, 2008 at 5:09 PM, David W. Fenton
[EMAIL
On 19 Aug 2008 at 16:41, Eric Dannewitz wrote:
Point is that the original poster is not a database worker. And has no plans
on having tens of thousands of things in the database. c
Show me where in Johannes' original post where he says any of these
things:
On 19 Aug 2008 at 7:38, Johannes
On 20 Aug 2008 at 2:04, shirling neueweise wrote:
why the reactionary response to relational DB structures?
Eric always has to disagree with any position I'm advocating.
[only half joking]
--
David W. Fentonhttp://dfenton.com
David Fenton Associates
My position does have merit. I worked as a DBA (Database Administrator) for
two years in a startup that was eventually sold off to the University Of
Phoenix. I dealt with hundreds of thousands of tests that came in flat file
and we had to design aggregated table structures for them. All in Oracle.
On 19 Aug 2008 at 17:14, Eric Dannewitz wrote:
Geeze, go back and read the ORIGINAL POST
My orchestra needs to create a database for its small, but growing music
library. Can someone give me some hints on how to do this, preferable on a
Mac? I want something which is easy to maintain and
On 19 Aug 2008 at 17:16, Eric Dannewitz wrote:
I give up. Fine. Get the guy a relational database. Hell, get him an Oracle
one. Might as well get the best right? Who knows how many times he'll need
to run queries on how many string parts a Mozart concerts from XYZ edition
have..
It
On Aug 19, 2008, at 8:09 PM, David W. Fenton wrote:
But a flat file approach is guaranteed to produce far more problems
in the long run than are possible with a relational structure, unless
that, too, has been improperly designed.
David,
You seem to have a lot of experience here. Assuming
On 19 Aug 2008 at 17:21, Eric Dannewitz wrote:
I have the experience.
It's too bad your posts to this list on this subject do not exhibit
any evidence of that experience.
It is totally overkill setting up a huge relational thing
Nobody suggested a huge relational thing -- that's a straw
Fine David. You are right. As always. You obviously know every thing. As
usual. And you personally attack. Yet again.
Moron.
On Tue, Aug 19, 2008 at 5:25 PM, David W. Fenton
[EMAIL PROTECTED]wrote:
On 19 Aug 2008 at 17:16, Eric Dannewitz wrote:
I give up. Fine. Get the guy a relational
Table for InstrumentsTable for Part (first, second, third) Table for
Composers and their Bio (assuming both those are unique)
Table for Style Of The Piece
Table for the Piece which would have pointers to Composers and Style and to
a table which has
Parts (which has a pointer to Instruments and
Fenton, shut the fuck up guy.
Other people suggested Excel, or even file cards. It worked well for them.
Why not the original poster? So I chime in and say I think it is overkill to
have a relational database. Then you go off on a tangent again. As usual.
Oh, and start belittling people. As usual.
I would strongly support FileMaker Pro, it does a wonderful job and I
use it for all our orchestra info.
Re the borrowing information---it might be better to have a separate
file for that as the number of fields required in one file would
perhaps be rather cumbersome. Also the information
On 19 Aug 2008 at 20:35, Christopher Smith wrote:
On Aug 19, 2008, at 8:09 PM, David W. Fenton wrote:
But a flat file approach is guaranteed to produce far more problems
in the long run than are possible with a relational structure, unless
that, too, has been improperly designed.
You
On 19 Aug 2008 at 21:18, Margaret whitby wrote:
I would strongly support FileMaker Pro, it does a wonderful job and I
use it for all our orchestra info.
Re the borrowing information---it might be better to have a separate
file for that as the number of fields required in one file would
Fine David. You are right.
ah, so i am too i guess, cool. i was starting to wonder... whew.
now i can sleep peacefully.
And you personally attack. Yet again.
Moron.
fighting fire with fire?
___
Finale mailing list
Finale@shsu.edu
Yes, snuggle up with your comfy whatever.
Fire with Fire is the only way a Fenton works..
On Tue, Aug 19, 2008 at 6:27 PM, shirling neueweise
[EMAIL PROTECTED] wrote:
Fine David. You are right.
ah, so i am too i guess, cool. i was starting to wonder... whew. now i can
sleep
Fenton, shut the fuck up guy.
er... that's conversational fascism, and worse than anything you've
accused david of, in my HUGEly underappreciated opinion.
Other people suggested Excel, or even file cards. It worked well for them.
(sigh)
again: no one has denied these methods can work.
On Aug 19, 2008, at 6:45 PM, shirling neueweise wrote:
again: no one has denied these methods can work. several people
have pointed out the benefits of relational DB over a flat
structure, which you seem to disagree with. fine, but just because
you disagree doesn't mean you're right,
On 19 Aug 2008 at 19:21, Eric Dannewitz wrote:
I'm not going to argue that
a relational database isn't a good thing. It is. For huge amounts of
data.
You really understand *nothing* about proper database design if you
think the *amount* of data involved determines what the level of
Yeah David, your right. I know nothing. I suppose the 2 years I made money
doing the rather boring work of being a DBA doesn't mean anything. Nor the
time I spent building a rather amazing database that would take a test, and
break it up into a dizzying array of tables. Plus all the statistical
At 4:21 PM -0700 8/19/08, Eric Dannewitz wrote:
Again, we are floating off topic. I don't believe the original poster is
going to track anything that is going to morph into this FUD case you are
trying to make a flat database out to be. It would totally work fine for
what the original posters
FileMaker can do both if you wanted. Flat database would be like index
cards. Relational database is more like a spider web, where there are little
parts that are related to multiple things.
On Tue, Aug 19, 2008 at 8:09 PM, John Howell [EMAIL PROTECTED] wrote:
At 4:21 PM -0700 8/19/08, Eric
From your friendly list owner,
Please refrain from two-sided shouting matches in what is a public forum.
Regardless of the dynamics involved, profanity and impolite discourse have no
place here.
The Finale list will remain a public forum, open to all; however, I can and
will bar membership to
62 matches
Mail list logo
