Can one create an MS Access table in Delphi (e.g., FireDAC) from the field defs of an existing table without using SQL?

Question

I wanted to create a new mdb file containing tables based on the structure of previously existing tables. I knew that I can use newTable.FieldDefs.Add() to recreate the fields one by one in a loop. But since there is already an oldTable fully stocked with the correct FieldDefs, that seemed terribly inelegant. I was looking for a single-statement solution!

I had found that newTable.FieldDefs.Assign(oldTable.FieldDefs) would compile (and run) without error but it left newTable with zero defined fields. This caused me to erroneously conclude that I didn't understand that statement's function. (Later I found that it failed only when oldTable.open had not occurred, which could not happen when the database was not available, even though the FieldDefs had been made Persistent and were clearly visible in the Object Inspector)

Here is my original code after some sleuthing:

procedure TForm2.Button1Click(Sender: TObject);
var
  fname: string;
  Table: TFDTable;
  FDConn: TFDConnection;

begin
  fname := 'C:\ProgramData\mymdb.mdb';
  if FileExists(fname) then DeleteFile(fname);

  { Make new file for Table }
  FDMSAccessService1.Database := fname;
  FDMSAccessService1.DBVersion := avAccess2000;
  FDMSAccessService1.CreateDB;

  { Connect to new file }
  FDConn := TFDConnection.Create(nil);
  FDConn.Params.Database := fname;
  FDConn.Params.DriverID := 'MSAcc';
  FDConn.Connected := true;

  { Set up new Table using old table's structure }
  Table := TFDTable.Create(nil);
  try
    { ADOTable1 has been linked to an existing table in a prior
      database with Field Defs made Persistent using the Fields
      Editor in the Object Inspector. That database will not be
      available in my actual use scenario }
    try
      ADOTable1.open; // Throws exception when database file not found
    except
    end;
    Table.Connection := FDConn;
    { specify table name }
    Table.TableName := ADOTable1.TableName;
    Table.FieldDefs.Assign(ADOTable1.FieldDefs);  // No errors reported
    ShowMessageFmt('New Table %s has %d fields',[Table.TableName,
      Table.FieldDefs.Count]);
    { Reports correct TableName but "0 fields" with table not open
      (i.e. file not found). Reports "23 fields" with table open }
    { Set Table definition into new mdb file }
    Table.CreateTable(False); // Throws exception when 0 fields found
  finally
    Table.Free;
  end;

end;

It turned out that the solution was to use a ClientDataSet originally linked to the same old database instead of the ADOTable. See the working solution below in my answer.

Edit: A final note. I had hoped to use this FireDAC approach, as indicated here, to get around the lack of a TADOTable.CreateTable method. Alas, although the "solutions" above and below do work to create a new TADOTable, that table's field definitions are not faithful replicas of the original table. There may be a combination of the myriad TFDTable options that would get around this, but I was not able to discover it so I reverted to creating my ADO tables with SQL.

Answer 1

Thanks to @Ken White's (unfortunately deleted) pointer, I now think that I have a solution to my original question about cloning the field defs from an old table into a newly created database. My original problem stemmed from the fact that the FieldDefs function for a table evidently does not return the actual stored field data if the table is not "open" (i.e., connected to the relevant database). Since my use scenario would not have a valid database available I could not "open" the table. However, ClientDataSets have an additional option to "StoreDefs" along with editor options to "Fetch Params" and "Assign Local Data". With those settings saved, the ClientDataSet renders its FieldDefs properties without being "open". Using that approach it seems that I can clone the stored field defs to a new table without needing a currently valid database to read them from. Thanks again, Ken, you saved a lot of my remaining hair! I sure wish that Embarcadero would do a better job of rationalizing their help files. They removed BDE from the default installation of Rio while still pointing in their help file discussion on creating Access tables to its TTable type as the way to create new tables and then never point to the equivalent capabilities in FireDAC (or elsewhere) which they continue to support. I wasted a lot of time because of this "oversight"!

Here is my working code after Ken's tip:

procedure TForm1.Button1Click(Sender: TObject);
var
i: integer;
fname: string;
Table: TFDTable;
FDConn: TFDConnection;

begin
  fname := 'C:\ProgramData\mymdb.mdb';
  if FileExists(fname) then DeleteFile(fname);
  FDMSAccessService1.Database := fname;
  FDMSAccessService1.DBVersion := avAccess2000;
  FDMSAccessService1.CreateDB;

  FDConn := TFDConnection.Create(nil);
  FDConn.Params.Database := fname;
  FDConn.Params.DriverID := 'MSAcc';
  FDConn.Connected := true;

  Table := TFDTable.Create(nil);
  try
    Table.Connection := FDConn;
    { specify table name }
    Table.TableName := 'ATable';
    { The existingClientDataSet has been linked to a table in the
      prior, no longer valid, database using StoreDefs, Fetch Params,
      and Assign Local Data in the Object Inspector }
    Table.FieldDefs.Assign(existingClientDataSet.FieldDefs);
    ShowMessageFmt('New Table has %d fields', [Table.FieldDefs.Count]);
    Table.CreateTable(False);
  finally
    Table.Free;
  end;