Re: WHY

From: Bill Sharpe (bsharpe_at_nsadelphia.net)
Date: 12/23/04 

Date: Thu, 23 Dec 2004 14:24:24 -0800

It must be very easy to create an amortization table in Access.
Searching Access help online gives no results for "amortization."
Obviously it's a trivial task, needing no help entry.

Why don't you show us how it's done, Aaron?

Bill Sharpe

<aaron_kempf@hotmail.com> wrote in message
news:%23oHnpPr5EHA.3472@TK2MSFTNGP09.phx.gbl...
you guys are crazy, i can create that in a database.. just as easily as
you
can create it in a spread***.

Are you retarded?

Do you really think that I can't store that information in a table?

Also-- if you're talking about the whole pivot ability.. There is a
wizard
to pivot this and in SQL2005; pivot and unpivot is a reality.

Are you really too retarded to realize that i can put this in a table
just
as easily as you can put it in a spread***?

And you're seriously bitching about how this is 'too complex'

hahahahahhaa

grow up and learn SQL kid

"Frank Kabel" <frank.kabel@freenet.de> wrote in message
news:umq%23QB84EHA.936@TK2MSFTNGP12.phx.gbl...
> Hi
> I think Harlan will respond anyway but
>
> > And about the exchange rate thing
> > A properly normalized table would have
> > Exhcnage Rate, Country,
>
> Very interesting approach but maybe you don't understand what exchange
rates
> are? Rates are defined BETWEEN two countries. So you need at least
> both
> countries to determine the respective exchange rate basis (and I hope
> you
> don't want to base all rates on one currency, e.g. US$ and calculate
> all
> other rates between different countries based on this as this won't
> work
in
> real live!)
>
>
> > But if you're bitching about being able to have a FromUsa and ToUk,
> > you
> > could have the same fields in a table that you do in your
> > spread***.
>
> You may read Harlan's post a little bit more carefully. He's talking
> about
a
> column heading and a row heading and using the intersection of a row
> and
> column to determine the respective exchange rate. So something like
> A B C D
> 1 USD YEN EUR
> 2 USD 1 120 0.83
> 3 YEN .... 1 ....
> 4 EUR 1.30 .... 1
>
>
> And this is something you can't directly translate to a database.
> You'd
> probably create a table such as
> From_Country
> To_Country
> Rate
>
> in this case with 9 records. Of course also not really a big issue but
> in
> this case I'd consider the spread*** more intuitive. A database may
> have
> benefits if I have to store the exchange rates other several days,
> months,
> etc though. (as stated always a question of choosing the right tool)
>
> And again for some kind of applications a database is just the wrong
> type
of
> tool. You really may try to answer Harlan's test examples with a
> database
> type of application. It would definetly be more difficult
>
> Frank
>
>
>
>

Loading