I get only a runtime error.
The same functions on a pc running full access 2000 works perfect.
What can I do?
You should as a rule "test" you code on your pc, and just use the /runtime
switch to get the "same" effect.
The one thing that "gets" you is that you can't launch, or automate a 2nd
copy of ms-access using the runtime (the reason for this is that ms-access
as runtime REQUIRES A FILE NAME as parameters, and when you automate, this
is NOT possible to provide).
I can't remember why, but a number of years ago, my code to modify the back
end also used automaton..and when I went to runtime mode...it failed.
So, the simple solution is to have your code OPEN the back end database, and
modify it. You should NOT need to automate a 2nd copy of ms-access to create
your modifying.
so, here how I do this:
' check table locations...and add default capacity...
' check for Locations capacity field
Dim nF As DAO.Field
Dim nT As DAO.TableDef
Dim nR As DAO.Relation
Dim rst As DAO.Recordset
Dim dbTable As DAO.TableDef
Dim db As DAO.Database
Dim strTemp As Variant
Set rst = CurrentDb.OpenRecordset("Locations")
On Error GoTo AddLocationsCapacity
strTemp = rst!Capacity.Name
rst.Close
Set rst = Nothing
return
AddLocationsCapacity:
rst.Close
strToDB = strBackEndPath
Set db = OpenDatabase(strToDB)
Set nT = db.TableDefs("Locations")
nT.Fields.Append nT.CreateField("Capacity", dbLong)
nT.Fields.Refresh
db.Close
Set db = Nothing
Set rst = CurrentDb.OpenRecordset("Locations")
resume next
Notice how we simply grab (create) a "db" object on the back end.
So, if we were not split, we would go:
set db = currentdb
now, we use
set db = OpenDataBase("path to back end")
From this point on, you can use your alter table commands etc...
db.Execute "alter table......"
when done,
db.Close
So, don't launch a 2nd copy of ms-access via automaton...it not only
resource intensive, but simply can't be done via the runtime....
The above "error" handling is how I ignore the creating of the field the 2nd
time....
