
14th August 2006, 10:49 PM
|
Member
|
|
Join Date: Jan 1970
Posts: 1,096
|
|
Quote:
Originally Posted by Chrome Prince
Iomaca,
Ranking by career prizemoney for example:
$1,000,000 1
$900,000 2
$750,000 3
$200,000 4
$100,000 5
etc
It can of course be done, but not easily enough for my liking and is cumbersome.
The problem is getting access to recognize the difference between two records, not between two fields.
I don't want to create a report with the info or even a query, I want to update tables, which is near impossible. Of course, I could perform a sort and then insert the ranking, but the program does not recognize a different race or venue or date as per previous / next record.
Ideally what is needed is a database that recognizes Excel formulae and can calculate between records.
At present I have a query within a query within a query, and it's getting very difficult to make changes or add queries when there are so many "layers"
|
OK I see what you mean.
It's just that you mentioned date-track-racenumber in your original post.
Creating a primary key based on these fields would be a basic prerequisite of designing a database table, I would have thought, thus keeping table integrity (elminating duplicate records etc.)
As for queries, at work we only use databases as a repository of data and all query work is done programmatically via VB, C++ etc. This makes writing applications portable, you only have to make a reference to the type of database you are using in code (like "mdb, dbs etc.") as a matter of fact even Excel can be referenced this way.
I have to agree with you re. Excel, it's very good what it was made for but a database it ain't. Still, if it does what you want it to do? why not use it?
Cheers
|