First off, I'm using Access 2000 and DAO. I have code that executes a simple INSERT INTO query that I call using db.Execute. This code works fine inside an mdb. However, if I compile into an mde then I get
error 5 - Invalid procedure call or argument
on this line and the record does not get inserted. However, if I change from db.Execute to DoCmd.RunSQL using the exact same SQL statement the record is inserted with no problems. Does anyone know why the DAO Execute method of the DAO database object would suddenly stop working once I compile into an MDE?
Note: I only get the error if I specify the dbFailOnError option of the .Execute method. If I leave that option off, I get no error but the record is still not inserted.
EDIT:
This line fails in the MDE (but works fine in the MDB):
App.db.Execute InsertSQL, dbFailOnError
From the immediate window with a breakpoint on the above line of code:
?InsertSQL
INSERT INTO Changes
(PropertyID, FieldID, [Which], [When], [Before], Reason, ReportChange)
VALUES (1, 2, "M", #2/19/2010 4:51:44 PM#, "Suite 2; 430 W KING ST; ABBOTTSTOWN, PA 17301-9771", "Per Owner", True)
(I have an entire class module dedicated to building and executing SQL statements, so it's not really practical to show exactly how I built the InsertSQL string variable. However, I really don't think that is relevant.)
This line works everywhere:
DoCmd.RunSQL InsertSQL
EDIT: App.db definition (note that there is no reference in my project to ADO, only DAO):
Public App As New clsApp
clsApp class module (relevant lines only):
Private m_objDB As Database
Public Property Get db() As Database
Set db = m_objDB
End Property
Private Sub Class_Initialize()
Set m_objDB = CurrentDb
End Sub
Private Sub Class_Terminate()
Set m_objDB = Nothing
End Sub
If you are curious, I use App.db rather than CurrentDB for two main reasons: 1) slight performance gain by not having to call the CurrentDB function repeatedly (call it once then just refer to the object it returns) and 2) properties of the database object like .RecordsAffected always return relevant information. Plus, it's faster to type. And I'm a programmer, so I'm inherently lazy.
EDIT: Let me first apologize to those who have been following this thread and trying to help me. It seems I may have left out the critical details of my problem. The App.db.Execute call takes place inside a class module (clsSQL) and it references a global variable named App which is itself an instance of a different class module (clsApp). I'm guessing the problem is that I am referring to an instance of a class module from within another class module. Can anyone confirm if calling one class module from within another is something that is supported by MDBs and not MDEs? [It is not an issue. I was way over-thinking this. See my answer for the full story.]
Chances are you are using a forms control reference inside the string you are passing to the Execute statement. That is me!ControlName is inside the quotes. Change it so it's outside the quotes. That is change ".... SELECT me!ControlName As Field1, Field2, Field3 ..." to ".... SELECT " & me!ControlName & " As Field1, Field2, Field3 ..."
Thus VBA can convert the value of the control name properly. Docmd.RunSQL does this for you. Execute does not.
Firstly, my sincere apologies to those who tried to help me with this. As I find so frustrating when others ask questions, I left out the key piece of information because I did not think it was relevant. Here was the full initialize procedure for my clsApp class module:
Private Sub Class_Initialize()
Application.Echo True
m_bEcho = True
Set m_objDB = CurrentDb
m_sUser = GetUserName
Set m_objStatus = New clsStatus
m_sPgmName = Application.CurrentProject.Name
m_sPgmName = Left(m_sPgmName, InStr(m_sPgmName, ".mdb") - 1)
End Sub
The key line is that last one. When I compiled into an ".mde", the string ".mdb" was no longer present in the CurrentProject.Name. As a result, the call to InStr() returned 0. And 0 - 1 = -1. So I was passing a negative number as the Length parameter for the Left() function. However, the length parameter cannot be negative. It is most definitely an "Invalid procedure call or argument."
My simple fix was to remove the "mdb" from ".mdb" and just check for the location of the "." This also works correctly with the ".accdb" and ".accde" 2007 extensions.
Again, my apologies.
What version of DAO do you have in your references? It might be that the older version is working fine on the mdb but fails on the mde. Try setting this to the latest version and compile it again
Related
Let me start by saying I am not at all familiar with Access or VBA. However, I am the IT guy and at some point someone created an MS Access database that does a thing and now I have to support it.
We have a database that upon opening deletes any old data and re-runs the external query that makes this application work. Occasionally whatever state the program exited out in that table already does not exist. This causes MS Access to hang on the delete line and I have to run the debugger, comment out the DoCmd.DeleteObject line, re run, and then un-comment the line to let the user continue with their day.
I want to add in some sort of conditional statement, but anything I've been able to google in terms of If...Then statements or 'TableExist' type functions always causes an error to be thrown that I haven't defined the function. My best guess is I'm nesting this incorrectly or I'm not calling some sort of external function correctly, but as I said my VBA knowledge is extremely limited.
This code executes on startup:
Public Function Startup() As Integer
DoCmd.Close acForm, "soLookup"
DoCmd.DeleteObject acTable, "sales_order"
DoCmd.RunSavedImportExport "Import-sales_order"
DoCmd.OpenForm "soLookup"
End Function
Its the
DoCmd.DeleteObject acTable, "sales_order"
Line that causes things to fail.
I've attempted to restructure this several times based on several examples I had found, but I'll only bother with one below
Public Function Startup() As Integer
DoCmd.Close acForm, "soLookup"
If TableExists("sales_orders") Then
DoCmd.DeleteObject acTable, "sales_orders"
Else
'Do nothing
End If
DoCmd.RunSavedImportExport "Import-sales_order"
DoCmd.OpenForm "soLookup"
End Function
Nothing I seem to try seems to give me any result other than an error of some sort. All I want to do is add a conditional statement to this 'Startup' bit that checks if the "sales_order" table even if exists, and if it doesn't, then to just move on to the next comment and forget the DoCmd.DeleteObject. How can I achieve this functionality?! Thanks!
The TableExists function is not a standard function in Access. You need to define it yourself.
There are two main ways to define such a function, by trying and error trapping, or by iterating through all tables and checking names.
Way 1 (error trapping):
Public Function TableExists(TableName As String) As Boolean
On Error Resume Next
TableExists = CurrentDb.TableDefs(TableName).Name = TableName
End Function
Way 2 (iterating collection):
Public Function TableExists(TableName As String) As Boolean
Dim td As DAO.TableDef
For Each td In CurrentDb.TableDefs
If td.Name = TableName Then
TableExists = True
Exit Function
End If
Next
End Function
Define either of these functions in a public module, and your last approach should work
I will instead modify the query to import the source data into a new table (sales_orders), which will overwrite existing data when the query runs and so I don't have to delete the table and have additional check for TableExists
I have a small bit of code for a much larger MS Access database that likes to behave erratically. I can't say for sure, but it seems to change when I compile or recompile the database. Here's the code:
Private Sub FindCtls()
Dim DatType as String
Dim thisCTL as Control
DatType = Right(ActiveControl.Name, Len(ActiveControl.Name)-4)
For Each thisCTL In Me.Controls
If InStr(1, thisCTL.Name, DatType, 2) > 0 Then
Select Case Left(ThisCtl.Name,4)
Case "Sel_"
Set TgtCtls(0) = thisCTL
' A buncha other Cases
End Select
End If
Next thisCTL
End Sub
The problem is, when I step through the code, for some reason thisCTL is being passed as the value of the control, not the control itself. I've looked everywhere for this answer, that brought me to using the "Set" command instead of just putting TgtCtls(0) = thisCTL. That worked until I decompiled the DB and recompiled it. Made one change (changed the name of the first variable), compiled it again, and it worked. As I got into work today, someone told me that it was no longer working. Any ideas would be greatly appreciated.
Edit: I forgot to mention that TgtCtls is a form-wide array that was Dim'd at the top as such:
Option Compare Database
Dim TgtCtls(2) as Control
I am trying to insert some records into MS Access Table with the help of below VB Script. But when am trying to execute it, it's throwing Compilation error: Expected end of statement. Could someone please help me figure out where am I going wrong.
Private Sub Form_Click()
Dim dbs As DAO.Database
Dim DbFullNAme As String
DbFullName = "D:\G\Diamond\FINAL MS-Access\MS-Access project.accdb"
Set dbs = OpenDatabase(DbFullName)
dbs.Execute "INSERT INTO [2014_Status] ( Prompt, Project_Name, STATUS,Release_Name )SELECT RoadMap.SPRF_CC, RoadMap.SPRF_Name, RoadMap.Project_Phase,RoadMap.Release_Name FROM RoadMap WHERE (((Exists (select 1 FROM [2014_Status] where RoadMap.SPRF_CC = [2014_Status].[Prompt]))=False));"
dbs.Close
End Sub
VBScript (as opposed to VBA or other dialects) does not support typed Dims. So
Dim dbs As DAO.Database
Dim DbFullNAme As String
need to be
Dim dbs
Dim DbFullNAme
VBscript has no native OpenDatabase() function. You need to use ADO to connect to your Access 'database'. First create a connection
Set dbs = CreateObject("ADODB.Connection")
Then determine the connection string and
dbs.Open cs
The rest of your code should work.
Update wrt comment:
The error message:
D:\G\Diamond\FINAL MS-Access\query1.vbs(2, 9) Microsoft VBScript compilation error: Expected end of statement
prooves that the OT tried to write a VBScript (the addition of the misleading vba/access tags is (C) Pankaj Jaju).
So lets break down the real reason why this code doesn't work.
You copied and pasted Visual Basic for Applications(VBA) into a .VBS(Visual Basic Script) file and expected it to work, I assume.
The problem with this is that VBA and VBScript are slightly different languages. Review the info section for both tags on stackoverflow when you get the opportunity.
For now lets just patch your code and maintain your DAO object so you don't have to reconstruct your Database usage with ADODB.
ExecuteInsert
Sub ExecuteInsert()
Dim dbs, DbFullName, acc
Set acc = createobject("Access.Application")
DbFullName = "D:\G\Diamond\FINAL MS-Access\MS-Access project.accdb"
Set dbs = acc.DBEngine.OpenDatabase(DbFullName, False, False)
dbs.Execute "INSERT INTO [2014_Status] ( Prompt, Project_Name, STATUS,Release_Name )SELECT RoadMap.SPRF_CC, RoadMap.SPRF_Name, RoadMap.Project_Phase,RoadMap.Release_Name FROM RoadMap WHERE (((Exists (select 1 FROM [2014_Status] where RoadMap.SPRF_CC = [2014_Status].[Prompt]))=False));"
dbs.Close
msgbox "done"
End Sub
Changes made.
Blocked your dim'd variables and removed As *** statements for vbscript compatibility
Set an access object so you could maintain the remainder of your code.
Added the acc.DBEngine. before OpenDatabase with additional parameters.
Renamed your Sub from Form_Click to ExecuteInsert, then placed ExecuteInsert at the top of the code so that the vbscript activates the sub. If you just place a sub in a vbscript file, it will not necessarily run, you have to activate it directly.
This code is tested and functions. Best of luck to you.
Adding to Ekkehard.Horner
http://www.csidata.com/custserv/onlinehelp/vbsdocs/vbs6.htm
VBScript has only one data type called a Variant. A Variant is a
special kind of data type that can contain different kinds of
information, depending on how it's used. Because Variant is the only
data type in VBScript, it's also the data type returned by all
functions in VBScript.
I am having one case and need your advice whether to use DoEvents() / Any Other / Nothing to use.
I have developed an application in VB 6.0 before 5-6 Years and is working fine.
Now From some time as Data is increased (MS Access), It gives some unexpected result.
I am using DbName.Execute "...Query to Update Tables..." and then after this line I had Used DoEvents(), to let DbName.Execute Query to be completed first and then go ahead with the rest of the code.
So Is it the right use of DoEvents(), as I had monitored that in some Advanced CPU, the problems occurs due to non executing the Query / Query is Running Still the rest of the code is executed
I actually want to Stop executing further code, once the Query Executed Completely, Then I want to execute further code
Please Guide !
The DAO and ADO .Execute methods both operate synchronously by default. In other words, the next line of code does not execute until the query finishes processing. You do not need to use DoEvents or While Loops or anything else.
You can force the Execute method to run asynchronously by setting the option flag dbRunAsync in DAO or adAsyncExecute in ADO. If either of these flags is set (you don't specify whether you are using DAO or ADO) then simply deleting them from the method call will force your code to wait until the query is done before going to the next line.
I think you can ensure your Execute operation has been completed and written to disk by operating it within a transaction. Here's what Access 2003 Execute Method help topic says about transactions:
For best performance in a Microsoft Jet workspace, especially in a multiuser environment, nest the Execute method inside a transaction. Use the BeginTrans method on the current Workspace object, then use the Execute method, and complete the transaction by using the CommitTrans method on the Workspace. This saves changes on disk and frees any locks placed while the query is running.
See if an approach likes this eliminates your unexpected result. If not, describe the unexpected result you're hoping to avoid.
Dim objWorkspace As DAO.Workspace
Dim db As DAO.Database
Dim strSql As String
On Error GoTo ErrorHandler
Set objWorkspace = DBEngine.Workspaces(0)
Set db = CurrentDb
objWorkspace.BeginTrans
strSql = "UPDATE YourTable SET some_field = Null;"
db.Execute strSql, dbFailOnError
'* additional db.Execute operations if desired *'
objWorkspace.CommitTrans
ExitHere:
On Error GoTo 0
Set db = Nothing
Set objWorkspace = Nothing
Exit Sub
ErrorHandler:
objWorkspace.Rollback
GoTo ExitHere
Yes, I got the same idea. I would do the following as you asked "whether or not to use DoEvents()
Dim i as long
i = 0
Do
i = i + 1
DoEvents() ' Is this what you were asking?
Loop Until i = 5000
There is some literature available at expert's exchange and at teck republic about using the combobox.recordset property to populate a combobox in an Access form.
These controls are usually populated with a "SELECT *" string in the 'rowsource' properties of the control, referencing a table or query available on the client's side of the app. When I need to display server's side data in a combobox, I create a temporary local table and import requested records. This is time consuming, specially with large tables.
Being able to use a recordset to populate a combobox control would allow the user to directly display data from the server's side.
Inspired by the 2 previous examples, I wrote some code as follow:
Dim rsPersonne as ADODB.recordset
Set rsPersonne = New ADODB.Recordset
Set rsPersonne.ActiveConnection = connexionActive
rsPersonne.CursorType = adOpenDynamic
rsPersonne.LockType = adLockPessimistic
rsPersonne.CursorLocation = adUseClient
rsPersonne.Open "SELECT id_Personne, nomPersonne FROM Tbl_Personne"
fc().Controls("id_Personne").Recordset = rsPersonne
Where:
connexionActive: is my permanent ADO connection to my database server
fc(): is my current/active form
controls("id_Personne"): is the
combobox control to populate with
company's staff list
Access version in 2003
Unfortunately, it doesn't work!
In debug mode, I am able to check that the recordset is properly created, with requested columns and data, and properly associated to the combobox control. Unfortunately, when I display the form, I keep getting an empty combobox, with no records in it! Any help is highly appreciated.
EDIT:
This recordset property is indeed available for the specific combobox object, not for the standard control object, and I was very surprised to discover it a few days ago.
I have already tried to use combobox's callback function, or to populate a list with the "addItem" method of the combobox,. All of these are time consuming.
To set a control that accepts a rowsource to a recordset you do the following:
Set recordset = currentDb.OpenRecordset("SELECT * FROM TABLE", dbOpenSnapshot)
Set control.recordset = recordset
Works with DAO Recordsets for sure, I haven't tried ADO recordsets because I don't have any real reason to use them.
When done this way, a simple requery will not work to refresh the data, you must do a repeat of the set statement.
As was said, you have to get the RowSourceType to "Table/Query" (or "Table/RequĂȘte" if in french) in order to show query results in the combobox.
Your memory problems arise from opening the recordset (rsPersonne) without closing it. You should close them when closing/unloading the form (but then again you would have scope problems since the recordset is declared in the function and not in the form).
You could also try to create and save a query with Access's built-in query creator and plug that same query in the RowSource of your combobox. That way the query is validated and compiled within Access.
I found the trick ... the "rowSourceType" property of the combobox control has to be set to "Table/Query". Display is now ok, but I have now another issue with memory. Since I use these ADO recordsets on my forms, memory usage of Access is increasing each time I browse a form. Memory is not freed either by stopping the browsing or closing the form, making MS Access unstable and regularly freezing. I will open a question if I cannot solve this issue
good method with using the Recordset property, thanks for that hint!
Patrick, the method you shown on your page has a big disadvantage (I tried that too on my own): The value list can only be 32 KB, if you exceed this limit the function will throw an error.
The callback method has the big disadvantage that it is very slow and it is called once for every entry which makes it unuseable for a longer list.
Using the recordset method works very well. I needed this because my SQL string was longer than 32 KB (lot of index values for WHERE ID IN(x,x,x,x,x...)).
Here's a simple function which uses this idea to set a recordset to the combobox:
' Fills a combobox with the result of a recordset.
'
' Works with any length of recordset results (up to 10000 in ADP)
' Useful if strSQL is longer than 32767 characters
'
' Author: Christian Coppes
' Date: 16.09.2009
'
Public Sub fnADOComboboxSetRS(cmb As ComboBox, strSQL As String)
Dim rs As ADODB.Recordset
Dim lngCount As Long
On Error GoTo fnADOComboboxSetRS_Error
Set rs = fnADOSelectCommon(strSQL, adLockReadOnly, adOpenForwardOnly)
If Not rs Is Nothing Then
If Not (rs.EOF And rs.BOF) Then
Set cmb.Recordset = rs
' enforces the combobox to load completely
lngCount = cmb.ListCount
End If
End If
fnADOComboboxSetRS_Exit:
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
Exit Sub
fnADOComboboxSetRS_Error:
Select Case Err
Case Else
fnErr "modODBC->fnADOComboboxSetRS", True
Resume fnADOComboboxSetRS_Exit
End Select
End Sub
(The function fnADOSelectCommon opens an ADO recordset and gives it back. The function fnErr shows a message box with the error, if there was one.)
As this function closes the opened recordset there should be no problem with the memory. I tested it and didn't saw any increasing of memory which wasn't released after closing the form with the comboboxes.
In the Unload Event of the form you can additionaly use a "Set rs=Me.Comboboxname.Recordset" and then close it. This should not be necessary regarding memory, but it may be better to free up open connections (if used with a backend database server).
Cheers,
Christian
A combo box control does not have a recordset property. It does have a RowSource property but Access is expecting a SQL string in there.
You can change the RowSourceType to the name of a user defined "callback" function. Access help will give you more information including sample code by positioning yourself on the RowSourceType and pressing F1. I use this type of function when I want to give the users a list of available reports, drive letters, or other data that is not available via a SQL query.
I don't understand what you mean by your third paragraph with respect to using data directly from the server side. Or rather I don't understand what the problem is with using standard queries.
In MS Access, it's ok, but in VB, you may use something like this using adodc (Jet 4.0):
Private sub Form1_Load()
with Adodc1
.commandtype = adcmdtext
.recordsource = "Select * from courses"
.refresh
while not .recordset.eof
combo1.additem = .recordset.coursecode
.recordset.movenext
wend
end with
End Sub