Table structure advice (can an FE add a field to a BE table at runtime?) (AC2007) (1 Viewer)

AOB

Registered User.
Local time
Today, 23:19
Joined
Sep 26, 2012
Messages
615
Hi all,

I am in the process of developing a DB which will have multiple tables, one of which will contain exchange rates for a number of currencies.

My current plan is to have one field for each currency, and one record for each date. The rates are imported from a file each day and the table is updated using some VBA which generates the necessary SQL command (this works fine)

The list of currencies should remain generally static; however, for the sake of flexibility, I do have within the VBA some code which checks if a new currency is present on the file (via a recordset) and, if necessary, adds a new field to the table :

Code:
With tdf
[INDENT].Fields.Append .CreateField(rst.Fields("Ccy"), dbDouble)
 
With .Fields(rst.Fields("Ccy"))
[INDENT].Properties.Append .CreateProperty("DecimalPlaces", dbByte, 4)
.Properties.Append .CreateProperty("Format", dbText, "0.0000")
[/INDENT]End With
 
[/INDENT]End With

However, I'm concerned that when I eventually split the DB into FE and BE, Access will not allow this design change to the backend table at runtime (although I haven't split it yet so not sure if this will actually be a problem?)

The alternative is to have a unique record for each currency / date combination, which would reduce the number of fields to just 3, but would see a dramatic increase in the number of records added each day (instead of just 1, there would be as many as there are currencies on the file)



Can anybody advise :
  1. Am I going to run into problems adding fields to the backend table from a frontend at runtime in this manner?
  2. If so, what is the best way for me to structure the table for data such as this (I'm sure I am not the first to have data in this format!)
Thanks in advance!

AOB
 

AOB

Registered User.
Local time
Today, 23:19
Joined
Sep 26, 2012
Messages
615
Thanks jdraw,

Yeah, I'm aware of that, but rates can vary depending on who you're asking; the rates I have are an agreed source. Plus, I need to do multiple calculations across an array of dates at any given time, so need to have an active table at arm's length rather than pulling arbitrary rates for arbitrary dates & currencies as and when I need them.

So still stuck with the same question?...

Cheers

AOB
 

spikepl

Eledittingent Beliped
Local time
Tomorrow, 00:19
Joined
Nov 3, 2010
Messages
6,142
The alternative is to have a unique record for each currency / date combination, which would reduce the number of fields to just 3, but would see a dramatic increase in the number of records added each day (instead of just 1, there would be as many as there are currencies on the file)

This "dramatic" route is nevertheless the correct one. Same kind of data should be stored in the same container (=field).
 

AOB

Registered User.
Local time
Today, 23:19
Joined
Sep 26, 2012
Messages
615
Sigh...

And I was so chuffed with myself for putting together the function to insert the fields :(

Thanks spikepl, that's what I suspected, I just needed validation from a more experienced source. I'll change the table...

Cheers!

AOB
 

spikepl

Eledittingent Beliped
Local time
Tomorrow, 00:19
Joined
Nov 3, 2010
Messages
6,142
You did a good job on creating your function. But just think: adding fields means, in general, changing queries, forms, reports, because there is a new field to play with. That indicates most often that that is not the way to go.
 

AOB

Registered User.
Local time
Today, 23:19
Joined
Sep 26, 2012
Messages
615
Sorry spikepl, a follow-on question...

What should I use as my primary key in the new design?

I will have duplicates within each of my date and currency fields, but I want to avoid records which have a common date AND currency. Surely not a concatenated field??
 

spikepl

Eledittingent Beliped
Local time
Tomorrow, 00:19
Joined
Nov 3, 2010
Messages
6,142
You have the three-letter currency designator and date. I'd use those as composite primary key (which is not a "concatenated field"). For composite PK, search here or google.
 

AOB

Registered User.
Local time
Today, 23:19
Joined
Sep 26, 2012
Messages
615
spikepl

Wonderful - I wasn't aware of composite primary keys!

This is perfect, thanks very much!

AOB
 

Users who are viewing this thread

Top Bottom