Doc man, this was what threw me
> if you add a field that contains the drive's serial number as a field name, then EVERY RECORD will have that same serial number as a field name because adding a field to a table is a "global" operation.
Because I was sure each field was different because its field name was different.
But with more of my code working I can see what you must have been describing. The First field worked as expected, the second field had the next field name, but the new data didn't start at the first row but at the first empty row.
> If instead you make a fixed field name called DriveSN or something like that, then put the serial number as data in that field in a single record, you have a searchable field (called DriveSN) that should only point to a single record - which is what databases normally do for a search operation.
So each drives Folder names, instead of being in a list, would be in row? What would be each columns field name?
This mightn't be so good for reading but no doubt there's some way to display it as a list. My idea was just to open the table.
I have about 20 USB drives with backup of backups..a big mess and want to consolidate them. The idea was this would display all the folder names at once. I bought an app called FolderMatch which lets you update and sync folders nicely.
I'll stop doing what I was and try your suggestion. I'm still a bit hazy but that might change as I see results
Josef_P I had changed the code to your Example 1. Although I may not need to add fields now.
You need to look up parent/child relationships. A relational database fully supports such concepts. When you talk about lists and rows, you may have a correct picture in your mind, but I keep coming back to the sound of Excel stepping into the conversation. I am guessing you want to store something related to backing up multiple folders on hard drives. It may not be what you want, but this is how I might store this in an Access hierarchy of tables.
table tDisks: DriveID (Autonumber primary key), DriveName (could be drive letter), SystemName (if you are backing up disks on more than one system), DriveSerial (your pesky serial number), DriveSize (KB or GB or whatever), other things solely related to a disk drive - but not content
table tFolders: FolderID (Autonumber primary key), DriveFK (foreign key to tDisks: DriveID), FolderName (or full folder path on drive), other things solely related to that folder
table tBackups: BackupID( Autonumber primary key), FolderFK (foreign key to tFolders: FolderID), info about when & where the backup was made - possibly including container-file names OR tape-cartridge IDs
From your confusion, it is clear that you would benefit from studying Database Normalization before you try to do too much in the wrong direction - which is where you WERE headed, but maybe we've caught you in time. IF you want to do some reading, you can search THIS forum for Normalization (because this IS a database forum) or you can search the web for Database Normalization (because by itself, the word "Normalization" appears in at least 6 major disciplines including Chemistry, Math, Psychology, Diplomacy, and a few more topics).
Once you've done that, you need to study JOIN queries because when we say "Relational Database" the mechanism that expresses relationships is the JOIN query.
FYI, I'm in USA Central Time Zone, in case you are trying to figure out my presence on the forum, which is approximately random anyway.