Need help with a DAO to ADO conversion

B

Bill

Without offering here any rationale as to why I need to
convert (you really don't want to know), I need to
convert the code segment below to use ADO. I can't
quite find sufficient details in HELP, particularly where
the TableDefs are concerned, to make the necessary
changes.

(Marshall Barton, Doug Steele and I have been screwing
with a bug for the last 4 days, so any help would be greatly
appreciated. See the "Requery Too Soon?" thread if you're
just dying to know what's behind this question.)
===============================================

Private Sub InitVer7pt1()
..
..
Dim booNotFound As Boolean
Dim dbCurr As DAO.Database
Dim tdfCurr As DAO.TableDef
Dim fldCurr As DAO.Field

IPDatabase = DLookup("InstDatabase", "InstProperties")

Set dbCurr = OpenDatabase(IPDatabase)
Set tdfCurr = dbCurr.TableDefs("InstProperties")
booNotFound = True

For Each fldCurr In tdfCurr.Fields
If fldCurr.Name = "InstDBVersion" Then
booNotFound = False
Exit For
End If
Next fldCurr

If booNotFound = True Then
Set fldCurr = tdfCurr.CreateField("InstDBVersion", dbSingle)
tdfCurr.Fields.Append fldCurr

Set fldCurr = tdfCurr.CreateField("InstAddress", dbText)
tdfCurr.Fields.Append fldCurr

Set fldCurr = tdfCurr.CreateField("InstCityState", dbText)
tdfCurr.Fields.Append fldCurr

tdfCurr.Fields.Refresh
..
..
..
..
End If

Set tdfCurr = Nothing
Set fldCurr = Nothing
dbCurr.Close
Set dbCurr = Nothing

End Sub
===============================================
 
D

Douglas J. Steele

You can use ADO object to run DDL, or you can use ADOX.

The DDL would look something like:

ALTER TABLE InstProperties
ADD COLUMN InstDBVersion SINGLE,
InstAddress TEXT,
InstCityState TEXT

and the following is an example of how to run DDL:

Sub RunDDL_ADO()
On Error GoTo Err_RunDDL_ADO

Dim conBackend As ADODB.Connection
Dim errConnect As ADODB.Error
Dim strBackend As String
Dim strDDL As String
Dim strErrors As String

strBackend = "H:\Databases\MyBackend.mdb"
strDDL = ""

Set conBackend = New ADODB.Connection
conBackend.Open _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source='" & strBackend & '"

conBackend.Execute strDDL

' Check whether any errors were returned
If conBackend.Errors.Count > 0 Then
If conBackend.Errors.Count = 1 Then
strErrors = "There is 1 error:" & vbCrLf
Else
strErrors = "There are " & _
conBackend.Errors.Count & _
" errors:" & vbCrLf
End If
For Each errConnect In conBackend.Errors
strErrors = strErrors & _
errConnect.Description & vbCrLf
Next errConnect
MsgBox strErrors
End If

End_RunDDL_ADO:
Set conBackend = Nothing
Exit Sub

Err_RunDDL_ADO:
MsgBox Err.Number & ": " & Err.Description
Resume End_RunDDL_ADO

End Sub

You can see an example of use ADOX at
http://msdn.microsoft.com/library/en-us/ado/html/678e5546-df5d-4cd0-bfe9-6cf13cb385c0.asp?frame=true

I personally don't believe it's anything to do with ADO vs DAO though.

What about trying to wrap a transaction around your table updates? The
CommitTrans method has a dbForceOSFlush parameter (it's wrongly identified
as dbFlushOSCacheWrites in some documentation. If in doubt, use its numeric
value, 1)
 
B

Bill

Doug,
I put a lot of credence to your comment:
"I personally don't believe it's anything to do with ADO vs. DAO though."

I would really prefer to leave the DAO in place, so before
I attempt to follow your suggestion regarding DDL, I would
point out that the current backend has already received its
field updates, so there's no TableDefs or Appends being executed
in the module. All I have to do to get the failure to occur is to
execute the DAO open and close. With that, do you think
attempting to, as you say, "wrap a transaction" would have
much meaning?

Bill
 
D

Douglas J. Steele

To be perfectly honest, I haven't been following the thread that closely. I
popped my head in a couple of times, and was able to address specific points
that were being raised, but I haven't looked at the bigger picture.

Looking back, your original post that you needed some way of ensure the
insert had taken place before the Requery in this code:

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"
CurrentDb.Execute tmpSQL
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

This might work:

Dim wksCurr As DAO.Workspace
Dim dbCurr As DAO.Database
Dim tmpSQL As String

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"

Set wksCurr = DBEngine.Workspaces(0)
Set dbCurr = wksCurr.Databases(0)
wksCurr.BeginTrans
dbCurr.Execute tmpSQL, dbFailOnError
wksCurr.CommitTrans, 1
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

might solve that problem.

To save me having to read everything else <g>, has the problem moved on to
something else?
 
B

Bill

Yes it has. In the beginning the symptoms pointed heavily
towards there being a problem in the class module that
attended to the insertion of a newly entered donation
value, the symptom being that the subsequent Requery
of the Recordsource of a subform failed to reveal the
new insertion.

As several attempts were made to identify what appeared
to be some sort of timing problem, I/we discovered that
the recently added DAO code in one of the general modules
was having some sort of "rippling" effect later on in the
application. (You might recall your having posted a
reply as to how to accomplish TableDefs and Appends.)
That was further isolated to the section of code wherein
the DAO DatabaseOpen and subsequent close occured.
That is, to cause the failure "downstream" in the application,
all I had to do was go through the DAO open/close sequence
with all of the related code commented out.

All of that experience is what gave rise to the idea that
perhaps there was some sort of bazaar interference
occurring between the DAO and ADO.....sort of "grasping
for straws". My intent was to satisfy once and for whether
there was any truth in that idea, so making the total application
ADO consistent would prove that out.

Bill


Douglas J. Steele said:
To be perfectly honest, I haven't been following the thread that closely.
I popped my head in a couple of times, and was able to address specific
points that were being raised, but I haven't looked at the bigger picture.

Looking back, your original post that you needed some way of ensure the
insert had taken place before the Requery in this code:

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"
CurrentDb.Execute tmpSQL
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

This might work:

Dim wksCurr As DAO.Workspace
Dim dbCurr As DAO.Database
Dim tmpSQL As String

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"

Set wksCurr = DBEngine.Workspaces(0)
Set dbCurr = wksCurr.Databases(0)
wksCurr.BeginTrans
dbCurr.Execute tmpSQL, dbFailOnError
wksCurr.CommitTrans, 1
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

might solve that problem.

To save me having to read everything else <g>, has the problem moved on to
something else?


--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Bill said:
Doug,
I put a lot of credence to your comment:
"I personally don't believe it's anything to do with ADO vs. DAO though."

I would really prefer to leave the DAO in place, so before
I attempt to follow your suggestion regarding DDL, I would
point out that the current backend has already received its
field updates, so there's no TableDefs or Appends being executed
in the module. All I have to do to get the failure to occur is to
execute the DAO open and close. With that, do you think
attempting to, as you say, "wrap a transaction" would have
much meaning?

Bill
 
D

David W. Fenton

All of that experience is what gave rise to the idea that
perhaps there was some sort of bazaar interference
occurring between the DAO and ADO.....sort of "grasping
for straws". My intent was to satisfy once and for whether
there was any truth in that idea, so making the total application
ADO consistent would prove that out.

I've not followed either of these discussions closely, but the lack
of the new record(s) showing up sounds like you're not refreshing a
connection or workspace somewhere. I don't see anything in the code
that would indicate, that, but in Douglas's code, he uses a separate
workspace, and I think you'd need to refresh the current workspace
in order for the data to show (or wait 1 second for the refresh
interval to kick in before requerying).

But I'm just throwing out possibilities to look at here.

I've had a similar intractable problem with a requery of a form
causing the following bookmark navigation to fail and know that
it's being caused by something complicated going on somewhere else
entirely, because I can't reproduce the problem outside its original
context.

These kinds of things are *very* frustrating, so I definitelyl
sympathize.
 
B

Bill

(PS) There are many places in the current application
wherein an insert is done into what is the underlying
Recordsource for a subform or even Rowsource of
a list box and the Requerys fail to show the newly
added record.

ALL those failures are triggered by the inclusion of
the open/close code of the DAO object. I.e., as soon
as the DAO related code is bypassed, everything
returns to proper functioning.

THIS IS A BUGGER!!!!!!!


Bill said:
Yes it has. In the beginning the symptoms pointed heavily
towards there being a problem in the class module that
attended to the insertion of a newly entered donation
value, the symptom being that the subsequent Requery
of the Recordsource of a subform failed to reveal the
new insertion.

As several attempts were made to identify what appeared
to be some sort of timing problem, I/we discovered that
the recently added DAO code in one of the general modules
was having some sort of "rippling" effect later on in the
application. (You might recall your having posted a
reply as to how to accomplish TableDefs and Appends.)
That was further isolated to the section of code wherein
the DAO DatabaseOpen and subsequent close occured.
That is, to cause the failure "downstream" in the application,
all I had to do was go through the DAO open/close sequence
with all of the related code commented out.

All of that experience is what gave rise to the idea that
perhaps there was some sort of bazaar interference
occurring between the DAO and ADO.....sort of "grasping
for straws". My intent was to satisfy once and for whether
there was any truth in that idea, so making the total application
ADO consistent would prove that out.

Bill


Douglas J. Steele said:
To be perfectly honest, I haven't been following the thread that closely.
I popped my head in a couple of times, and was able to address specific
points that were being raised, but I haven't looked at the bigger
picture.

Looking back, your original post that you needed some way of ensure the
insert had taken place before the Requery in this code:

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"
CurrentDb.Execute tmpSQL
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

This might work:

Dim wksCurr As DAO.Workspace
Dim dbCurr As DAO.Database
Dim tmpSQL As String

tmpSQL = "INSERT INTO [DonRegFam](FundID,DOE,FamilyID,Amount,Type)"
tmpSQL = tmpSQL & " VALUES(" & cboFunds.Column(0) & ", " & DVal & ", "
tmpSQL = tmpSQL & FamID & ", " & Me.AmtBox & ", " & TypeVal & ");"

Set wksCurr = DBEngine.Workspaces(0)
Set dbCurr = wksCurr.Databases(0)
wksCurr.BeginTrans
dbCurr.Execute tmpSQL, dbFailOnError
wksCurr.CommitTrans, 1
Me.DonationsSubform.Form.Requery
Me.CashBox = False
Me.AmtBox = 0
Me.AmtBox.SetFocus
Me.Record.Visible = False
Me.PrtStmtCmd.Visible = True

might solve that problem.

To save me having to read everything else <g>, has the problem moved on
to something else?


--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Bill said:
Doug,
I put a lot of credence to your comment:
"I personally don't believe it's anything to do with ADO vs. DAO
though."

I would really prefer to leave the DAO in place, so before
I attempt to follow your suggestion regarding DDL, I would
point out that the current backend has already received its
field updates, so there's no TableDefs or Appends being executed
in the module. All I have to do to get the failure to occur is to
execute the DAO open and close. With that, do you think
attempting to, as you say, "wrap a transaction" would have
much meaning?

Bill



You can use ADO object to run DDL, or you can use ADOX.

The DDL would look something like:

ALTER TABLE InstProperties
ADD COLUMN InstDBVersion SINGLE,
InstAddress TEXT,
InstCityState TEXT

and the following is an example of how to run DDL:

Sub RunDDL_ADO()
On Error GoTo Err_RunDDL_ADO

Dim conBackend As ADODB.Connection
Dim errConnect As ADODB.Error
Dim strBackend As String
Dim strDDL As String
Dim strErrors As String

strBackend = "H:\Databases\MyBackend.mdb"
strDDL = ""

Set conBackend = New ADODB.Connection
conBackend.Open _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source='" & strBackend & '"

conBackend.Execute strDDL

' Check whether any errors were returned
If conBackend.Errors.Count > 0 Then
If conBackend.Errors.Count = 1 Then
strErrors = "There is 1 error:" & vbCrLf
Else
strErrors = "There are " & _
conBackend.Errors.Count & _
" errors:" & vbCrLf
End If
For Each errConnect In conBackend.Errors
strErrors = strErrors & _
errConnect.Description & vbCrLf
Next errConnect
MsgBox strErrors
End If

End_RunDDL_ADO:
Set conBackend = Nothing
Exit Sub

Err_RunDDL_ADO:
MsgBox Err.Number & ": " & Err.Description
Resume End_RunDDL_ADO

End Sub

You can see an example of use ADOX at
http://msdn.microsoft.com/library/en-us/ado/html/678e5546-df5d-4cd0-bfe9-6cf13cb385c0.asp?frame=true

I personally don't believe it's anything to do with ADO vs DAO though.

What about trying to wrap a transaction around your table updates? The
CommitTrans method has a dbForceOSFlush parameter (it's wrongly
identified as dbFlushOSCacheWrites in some documentation. If in doubt,
use its numeric value, 1)


--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Without offering here any rationale as to why I need to
convert (you really don't want to know), I need to
convert the code segment below to use ADO. I can't
quite find sufficient details in HELP, particularly where
the TableDefs are concerned, to make the necessary
changes.

(Marshall Barton, Doug Steele and I have been screwing
with a bug for the last 4 days, so any help would be greatly
appreciated. See the "Requery Too Soon?" thread if you're
just dying to know what's behind this question.)
===============================================

Private Sub InitVer7pt1()
.
.
Dim booNotFound As Boolean
Dim dbCurr As DAO.Database
Dim tdfCurr As DAO.TableDef
Dim fldCurr As DAO.Field

IPDatabase = DLookup("InstDatabase", "InstProperties")

Set dbCurr = OpenDatabase(IPDatabase)
Set tdfCurr = dbCurr.TableDefs("InstProperties")
booNotFound = True

For Each fldCurr In tdfCurr.Fields
If fldCurr.Name = "InstDBVersion" Then
booNotFound = False
Exit For
End If
Next fldCurr

If booNotFound = True Then
Set fldCurr = tdfCurr.CreateField("InstDBVersion", dbSingle)
tdfCurr.Fields.Append fldCurr

Set fldCurr = tdfCurr.CreateField("InstAddress", dbText)
tdfCurr.Fields.Append fldCurr

Set fldCurr = tdfCurr.CreateField("InstCityState", dbText)
tdfCurr.Fields.Append fldCurr

tdfCurr.Fields.Refresh
.
.
.
.
End If

Set tdfCurr = Nothing
Set fldCurr = Nothing
dbCurr.Close
Set dbCurr = Nothing

End Sub
===============================================
 
D

Douglas J. Steele

David W. Fenton said:
I've not followed either of these discussions closely, but the lack
of the new record(s) showing up sounds like you're not refreshing a
connection or workspace somewhere. I don't see anything in the code
that would indicate, that, but in Douglas's code, he uses a separate
workspace, and I think you'd need to refresh the current workspace
in order for the data to show (or wait 1 second for the refresh
interval to kick in before requerying).

I thought I was using the current workspace

Set wksCurr = DBEngine.Workspaces(0)
Set dbCurr = wksCurr.Databases(0)
 
D

David W. Fenton

I thought I was using the current workspace

Set wksCurr = DBEngine.Workspaces(0)
Set dbCurr = wksCurr.Databases(0)

Well, sure, but the data is not showing up, so that suggests it's
*not* being updated. That's why I suggested refreshing the
workspace/database. Of course, now I see that there is no refresh
for either of these objects, just for the collections in them. As
you're not modifying the collections, there's no reason to refresh
them.

So, that was a dead end, I guess.
 
D

David W. Fenton

(PS) There are many places in the current application
wherein an insert is done into what is the underlying
Recordsource for a subform or even Rowsource of
a list box and the Requerys fail to show the newly
added record.

ALL those failures are triggered by the inclusion of
the open/close code of the DAO object. I.e., as soon
as the DAO related code is bypassed, everything
returns to proper functioning.

THIS IS A BUGGER!!!!!!!

Is this an ODBC data source?
 
B

Bill

As far as I know it is. The application employs a "standard"
(default) Access split mde/mdb configuration.
 
D

Douglas J. Steele

David's question (and a very good one that the rest of us didn't think to
ask!) is what is the backend database: a Jet database (i.e. an MDB or MDE
file), or some other DBMS?

If the BE's a Jet database, then it's not ODBC: you can't use ODBC to link
from an Access application to a Jet database.

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Bill said:
As far as I know it is. The application employs a "standard"
(default) Access split mde/mdb configuration.
 
B

Bill

Doug, you've ventured into an area in which I'm totally
ignorant. All I can tell you is that I started (moons ago)
with an "off-the-shelf" Access MDB database. As things
progressed, I split the MDB into a MDE frontend and
a MDB backend, where all the tables and user data
are maintained.

I've always believed that everything I was doing in this
application was "JET based". SQL, ADOBC are in
pervasive used in this application. . If I understand your
post correctly, then I'm NOT using ODBC. Hopefully
from my comments here you can confirm that??

Bill


Douglas J. Steele said:
David's question (and a very good one that the rest of us didn't think to
ask!) is what is the backend database: a Jet database (i.e. an MDB or MDE
file), or some other DBMS?

If the BE's a Jet database, then it's not ODBC: you can't use ODBC to link
from an Access application to a Jet database.
 
B

Bill

Doug,
As I posted earlier to Chuck Grimsby in the "Query Too Soon?"
thread, I finally understood what you were trying to teach me
regarding the use of DDL. In your post about DDL, you had
also cautioned about "adding blindly" and handling the error
when a field already existed. What would be the SQL query
to "softly" test for existance? It seems that if I can do that then
I can eliminate the DAO question completely and perhaps get
this problem "put to bed".

I have to tell you that all of you have been really great in
helping me with this problem, so thanks ever so much.

Bill


Douglas J. Steele said:
David's question (and a very good one that the rest of us didn't think to
ask!) is what is the backend database: a Jet database (i.e. an MDB or MDE
file), or some other DBMS?

If the BE's a Jet database, then it's not ODBC: you can't use ODBC to link
from an Access application to a Jet database.
 
D

Douglas J. Steele

One way of checking using strictly SQL would be to open a recordset using
SELECT * FROM Table, and loop through the Fields collection of the resultant
recordset, looking at the names of each field.
 
B

Bill

Doug,
I've converted the offending module to check for existing
fields using the fields collection of the open recordset, that
works fine.

Next, I replaced the old code with DDL ALTER TABLE,
but I get a runtime error:

Run-time error '3611':
Cannot execute data definition statements on linked data sources.

code:
strDDL = "ALTER TABLE InstProperties ADD InstDBVersion Single"
CurrentDb.Execute strDDL ', dbFailOnExecute

(Note dbFailOnExecute is commented out, as I get a compiler error.)

I must have missed something in all the postings that allowed me to
update table defs in the backend from a general module executing
in the frontend mde?

Bill
 
D

Douglas J. Steele

You need to instantiate an instance pointing to the actual database that
contains the tables.

Dim dbCurr As DAO.Database

dbCurr = OpenDatabase("C:\Folder\MyBackend.MDB")
dbCurr.Execute "DDL", dbFailOnError
dbCurr.Close
Set dbCurr = Nothing
 
B

Bill

HALLAULIA!!!!!!!!!!

Do me one last favor on this 30-hour marathon. Scan the final
code to see if there's a "snake-in-grass" just waiting to bite me.

I COULD NOT HAVE DONE THIS WITHOUT YOU DOUG!!!

=========( Begin Final Code)================================
Option Compare Database
Option Explicit
Dim conBackend As ADODB.Connection
Dim errConnect As ADODB.Error
Dim strBackend As String
Dim rsInstProp As ADODB.Recordset
Dim strSQL As String

Public Sub LoadInstProp()

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
' Here and only here is where one sets the current version of the TMS code.
' AND, where the compatibility version of the back-end database is set.
'
' The comparison at startup is to see if back-end is version compatible with
' the front-end code. I.e., If the IPDBVersion found in the Installation
' Properties table is "Equal" to the TMSDBVersion to which the current code
' is compatible.
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

TMSVersion = 7.2
TMSDBVersion = 7.1 'This ONLY changes when a TableDef changes.

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

strBackend = DLookup("InstDatabase", "InstProperties")

Set conBackend = New ADODB.Connection
conBackend.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source= '" &
strBackend & "'"

Call InitVer7pt1 '7.1 is the 1st version of field upgradable mdb's.

'==========================================================================
' This routine fetches the "Installation Properties" table and loads the
' corresponding global variables.
'==========================================================================



'Open the table containing the donation key.
strSQL = "SELECT * FROM [InstProperties]"
Set rsInstProp = New ADODB.Recordset
rsInstProp.Open strSQL, conBackend, adOpenKeyset, adLockOptimistic

If IsNull(rsInstProp!InstDBVersion) Then 'Null if we've just upgraded
rsInstProp!InstDBVersion = 7.1

If Len(IPAddress & "") > 0 Then
rsInstProp!InstAddress = IPAddress
Else
rsInstProp!InstAddress = "Please enter" 'User ignored prompt
End If

If Len(IPCityState & "") > 0 Then
rsInstProp!InstCityState = IPCityState
Else
rsInstProp!InstCityState = "Please enter" 'User ignored prompt
End If

rsInstProp.Update
End If

IPDBVersion = rsInstProp!InstDBVersion
IPName = rsInstProp!InstName
IPAcronym = rsInstProp!InstAcronym
IPPath = rsInstProp!InstPath
IPDatabase = rsInstProp!InstDatabase
IPImages = rsInstProp!InstImages
IPEmail = rsInstProp![InstE-mail]
IPAddress = rsInstProp!InstAddress
IPCityState = rsInstProp!InstCityState
IPPhone = rsInstProp!InstPhone
IPMDBRecip = rsInstProp![InstMDB-Recip]
IPRecipSubj = rsInstProp!InstRecipSubj
IPRecipMsg = rsInstProp!InstRecipMsg

'Close the properties table recordset.
rsInstProp.Close
Set rsInstProp = Nothing

Set conBackend = Nothing

If IPDBVersion < TMSDBVersion Then Call Upgrade


End Sub
Private Sub InitVer7pt1()
'==========================================================================
' TMS Version 7.1 is the first version of TMS where TableDef's are upgraded
' in the field. If the current DB is found to be without the InstDBVersion
' field within the Installation Properties, then DB needs to be upgraded to
' compatibility with at least version 7.1. THEN, after the Installation
' Properties are loaded in the main code (above), there will be checks to
' determine if further upgrades are required.
'==========================================================================

On Error GoTo Err_InitVer7pt1

Dim strDDL As String
Dim strErrors As String
Dim booNotFound As Boolean
Dim objFields As ADODB.Fields
Dim intIndex As Integer

booNotFound = True

strSQL = "SELECT * FROM [InstProperties]"
Set rsInstProp = New ADODB.Recordset
rsInstProp.Open strSQL, conBackend, adOpenKeyset, adLockOptimistic

Set objFields = rsInstProp.Fields

For intIndex = 0 To (objFields.Count - 1)
If objFields.Item(intIndex).Name = "InstDBVersion" Then booNotFound
= False
Next

'Release the lock. (Close the recordset)
rsInstProp.Close
Set rsInstProp = Nothing


If booNotFound = True Then

strDDL = "ALTER TABLE InstProperties ADD Column InstDBVersion
Single"
conBackend.Execute strDDL, dbFailOnError

strDDL = "ALTER TABLE InstProperties ADD Column InstAddress
text(50)"
conBackend.Execute strDDL, dbFailOnError

strDDL = "ALTER TABLE InstProperties ADD Column InstCityState
text(50)"
conBackend.Execute strDDL, dbFailOnError

IPAddress = InputBox("Your database has been updated to include two
new" & vbNewLine _
& "fields that are required for donation
statements" & vbNewLine _
& "suitable for submission to the IRS for tax
purposes." & vbNewLine & vbNewLine _
& "Please enter the mailing address of your
installation." & vbNewLine _
& "[We'll prompt for city, state and zip
momentarily.]")

IPCityState = InputBox("And now, the city, state zip of your
installation")
End If


'force Jet to finish any pending operations:
DBEngine.Idle dbRefreshCache

' Check whether any errors were returned
If conBackend.Errors.Count > 0 Then
If conBackend.Errors.Count = 1 Then
strErrors = "There is 1 error:" & vbCrLf
Else
strErrors = "There are " & _
conBackend.Errors.Count & _
" errors:" & vbCrLf
End If

For Each errConnect In conBackend.Errors
strErrors = strErrors & _
errConnect.Description & vbCrLf
Next errConnect
MsgBox strErrors
End If

End_InitVer7pt1:
Exit Sub

Err_InitVer7pt1:
MsgBox Err.Number & ": " & Err.Description
Resume End_InitVer7pt1

End Sub
Private Sub Upgrade()
MsgBox "Database at version " & IPDBVersion & "TMS requires it be at " &
TMSDBVersion
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
' New code is required here to perform necessary upgrades from known
versions.
' That means when TMS code requires an update to any TableDefs that code be
' inserted here to accomplish the modifications. For example, say we update
' TMS to version 8.3 and that version requires TableDef changes. We set
' TMSDBVersion to 8.3 and write the necessary code to modify the table
definitions
' accordingly and update the IPDBVersion of the database to match.
'
' Everytime such a change is necessary we iterate the code blocks until
we've
' taken the current back-end database incrementally to the highest level,
where
' each block takes us from one version to the next and so on.
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
End Sub
=========(End Final Code)=============================
 
D

Douglas J. Steele

Nothing untoward jumps out.

While I probably should have asked this a while ago, why are you bothing to
use ADO in LoadInstProp?

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Bill said:
HALLAULIA!!!!!!!!!!

Do me one last favor on this 30-hour marathon. Scan the final
code to see if there's a "snake-in-grass" just waiting to bite me.

I COULD NOT HAVE DONE THIS WITHOUT YOU DOUG!!!

=========( Begin Final Code)================================
Option Compare Database
Option Explicit
Dim conBackend As ADODB.Connection
Dim errConnect As ADODB.Error
Dim strBackend As String
Dim rsInstProp As ADODB.Recordset
Dim strSQL As String

Public Sub LoadInstProp()

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
' Here and only here is where one sets the current version of the TMS
code.
' AND, where the compatibility version of the back-end database is set.
'
' The comparison at startup is to see if back-end is version compatible
with
' the front-end code. I.e., If the IPDBVersion found in the Installation
' Properties table is "Equal" to the TMSDBVersion to which the current
code
' is compatible.
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

TMSVersion = 7.2
TMSDBVersion = 7.1 'This ONLY changes when a TableDef changes.

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

strBackend = DLookup("InstDatabase", "InstProperties")

Set conBackend = New ADODB.Connection
conBackend.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source= '" &
strBackend & "'"

Call InitVer7pt1 '7.1 is the 1st version of field upgradable
mdb's.

'==========================================================================
' This routine fetches the "Installation Properties" table and loads the
' corresponding global variables.
'==========================================================================



'Open the table containing the donation key.
strSQL = "SELECT * FROM [InstProperties]"
Set rsInstProp = New ADODB.Recordset
rsInstProp.Open strSQL, conBackend, adOpenKeyset, adLockOptimistic

If IsNull(rsInstProp!InstDBVersion) Then 'Null if we've just upgraded
rsInstProp!InstDBVersion = 7.1

If Len(IPAddress & "") > 0 Then
rsInstProp!InstAddress = IPAddress
Else
rsInstProp!InstAddress = "Please enter" 'User ignored prompt
End If

If Len(IPCityState & "") > 0 Then
rsInstProp!InstCityState = IPCityState
Else
rsInstProp!InstCityState = "Please enter" 'User ignored prompt
End If

rsInstProp.Update
End If

IPDBVersion = rsInstProp!InstDBVersion
IPName = rsInstProp!InstName
IPAcronym = rsInstProp!InstAcronym
IPPath = rsInstProp!InstPath
IPDatabase = rsInstProp!InstDatabase
IPImages = rsInstProp!InstImages
IPEmail = rsInstProp![InstE-mail]
IPAddress = rsInstProp!InstAddress
IPCityState = rsInstProp!InstCityState
IPPhone = rsInstProp!InstPhone
IPMDBRecip = rsInstProp![InstMDB-Recip]
IPRecipSubj = rsInstProp!InstRecipSubj
IPRecipMsg = rsInstProp!InstRecipMsg

'Close the properties table recordset.
rsInstProp.Close
Set rsInstProp = Nothing

Set conBackend = Nothing

If IPDBVersion < TMSDBVersion Then Call Upgrade


End Sub
Private Sub InitVer7pt1()
'==========================================================================
' TMS Version 7.1 is the first version of TMS where TableDef's are
upgraded
' in the field. If the current DB is found to be without the InstDBVersion
' field within the Installation Properties, then DB needs to be upgraded
to
' compatibility with at least version 7.1. THEN, after the Installation
' Properties are loaded in the main code (above), there will be checks to
' determine if further upgrades are required.
'==========================================================================

On Error GoTo Err_InitVer7pt1

Dim strDDL As String
Dim strErrors As String
Dim booNotFound As Boolean
Dim objFields As ADODB.Fields
Dim intIndex As Integer

booNotFound = True

strSQL = "SELECT * FROM [InstProperties]"
Set rsInstProp = New ADODB.Recordset
rsInstProp.Open strSQL, conBackend, adOpenKeyset, adLockOptimistic

Set objFields = rsInstProp.Fields

For intIndex = 0 To (objFields.Count - 1)
If objFields.Item(intIndex).Name = "InstDBVersion" Then booNotFound
= False
Next

'Release the lock. (Close the recordset)
rsInstProp.Close
Set rsInstProp = Nothing


If booNotFound = True Then

strDDL = "ALTER TABLE InstProperties ADD Column InstDBVersion
Single"
conBackend.Execute strDDL, dbFailOnError

strDDL = "ALTER TABLE InstProperties ADD Column InstAddress
text(50)"
conBackend.Execute strDDL, dbFailOnError

strDDL = "ALTER TABLE InstProperties ADD Column InstCityState
text(50)"
conBackend.Execute strDDL, dbFailOnError

IPAddress = InputBox("Your database has been updated to include two
new" & vbNewLine _
& "fields that are required for donation
statements" & vbNewLine _
& "suitable for submission to the IRS for tax
purposes." & vbNewLine & vbNewLine _
& "Please enter the mailing address of your
installation." & vbNewLine _
& "[We'll prompt for city, state and zip
momentarily.]")

IPCityState = InputBox("And now, the city, state zip of your
installation")
End If


'force Jet to finish any pending operations:
DBEngine.Idle dbRefreshCache

' Check whether any errors were returned
If conBackend.Errors.Count > 0 Then
If conBackend.Errors.Count = 1 Then
strErrors = "There is 1 error:" & vbCrLf
Else
strErrors = "There are " & _
conBackend.Errors.Count & _
" errors:" & vbCrLf
End If

For Each errConnect In conBackend.Errors
strErrors = strErrors & _
errConnect.Description & vbCrLf
Next errConnect
MsgBox strErrors
End If

End_InitVer7pt1:
Exit Sub

Err_InitVer7pt1:
MsgBox Err.Number & ": " & Err.Description
Resume End_InitVer7pt1

End Sub
Private Sub Upgrade()
MsgBox "Database at version " & IPDBVersion & "TMS requires it be at " &
TMSDBVersion
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
' New code is required here to perform necessary upgrades from known
versions.
' That means when TMS code requires an update to any TableDefs that code
be
' inserted here to accomplish the modifications. For example, say we
update
' TMS to version 8.3 and that version requires TableDef changes. We set
' TMSDBVersion to 8.3 and write the necessary code to modify the table
definitions
' accordingly and update the IPDBVersion of the database to match.
'
' Everytime such a change is necessary we iterate the code blocks until
we've
' taken the current back-end database incrementally to the highest level,
where
' each block takes us from one version to the next and so on.
'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
End Sub
=========(End Final Code)=============================
Douglas J. Steele said:
You need to instantiate an instance pointing to the actual database that
contains the tables.

Dim dbCurr As DAO.Database

dbCurr = OpenDatabase("C:\Folder\MyBackend.MDB")
dbCurr.Execute "DDL", dbFailOnError
dbCurr.Close
Set dbCurr = Nothing
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top