Up to a couple days ago I had this very simple script running just fine;
Set appAccess = CreateObject("Access.Application")
appAccess.OpenCurrentDatabase "\\mynetwork\myconnection\mydatabase.accdb"
appAccess.DoCmd.OpenQuery "Update", acViewNormal, acEdit
Set appAccess = Nothing
Unfortunately now, all of a sudden, throws me an error message:
I've tried Googling some solutions but it seems that the error code 800A09C5 is rather uncommon.
The interesting part is that this other code works fine, so I'm really confused as to why I'm getting the above error.
SET oAcc = CREATEOBJECT("Access.Application")
oAcc.OpenCurrentDatabase "\\mynetwork\myconnection\mydatabase.accdb"
oAcc.DoCmd.OutputTo acOutputTable, "PR_NOTES", "Excel97-Excel2003Workbook
(*.xls)", "\\mynetwork\OutputFiles\File_" & replace(FormatDateTime
(now,2),"/","-") & "at" & replace(FormatDateTime(now,4),":","-") &".xls", False, "",
, acExportQualityPrint
Any insight is appreciated.
This code line of:
appAccess.DoCmd.OpenQuery "Update", acViewNormal, acEdit
will not work for several reasons. First up the code constants of acViewNomral and code constant of acEdit are NOT part of vbScript, but are constants from Access. Vb scripting has NO idea what the value of these constants are. So you have to replace the constants with the actual values from Access. (so in the debug window in access you print out the constants by type in
? acViewNormal
And
? acEdit
Now a quick test shows above constants to be “0”, so you would replace the constants with a 0 (no quotes).
Next up your command is failing because you opening the query in EDIT mode – that mode is to edit and modify the query – not run the query.
Next up and a greater issue is when you use docmd. To execute a query, you will receive “dialog” boxes such as do you want to update all these rows yes/no – because of script and automation you will be un-able to click ok and answer yes to those prompts. You can change setwarnings, but most easy to just use the execute method.
So in the syntax of
appAccess.DoCmd.OpenQuery "Update"
should work – but then those nasty prompts such as "you are about to update xxx rows etc. will appear - and you can't answer those prompts in the script.
Better to use the execute method, and thus use
appAccess.currentdb.Execute "Update"
Related
I have a pass through query built in Teradata set to export data to an Excel spreadsheet. I'm trying to automate it, but when I run the macro or open the query, a window pops up asking for the data source. I have an ODBC connection created and I'm thinking there has to be a way to make the macro pass the data source name so it will run without interaction.
Edit: Adding Macro as requested
Function AutoExec()
On Error GoTo AutoExec_Err
DoCmd.OutputTo acOutputQuery, "Performance Interval Data", "ExcelWorkbook(*.xlsx)", _
"filepath\filename.xlsx", False, "", , acExportQualityPrint
DoCmd.Quit acExit
AutoExec_Exit:
Exit Function
AutoExec_Err:
MsgBox Error$
Resume AutoExec_Exit
End Function
Couple of concerns, (can't validate any of this right now as I do not currently have access to Access for testing), but it looks like:
You're trying to OutputTo a query, to the best of my knowledge that
is not feasible.
Your file path is setup as filepath\filename.xlsx unless that is the actual location and name of your Excel sheet, something seems
wrong there to me.
I don't really think this macro relates to an ODBC of any sort in its current state.
But, you should at least start with fixing the filepath issue. That should be the full path to your Excel file and the full name of the file as well. (i.e. C:\TEMP\TestExcelSheet.xlsx)
All that being said, you may want to just go with something like this (although its a little difficult to tell if this is what you actually want or not):
'Export Excel file from Query
DoCmd.TransferSpreadsheet acExport, , "acOutputQuery", _
"C:\TEMP\TestExcelSheet.xlsx", True
NOTE: "acOutputQuery" should be the actual name of your passthrough query, "C:\TEMP\TestExcelSheet.xlsx" would be your destination path, and True adds the query's headers into the sheet, False to ignore the headers.
I am trying to create a macro to update the value of a field in a form based off the results of a query.
I am entirely new to working with vba in Access so I apologize if I am asking a basic question.
I should mention, the "test" query returns exactly one result. It is essentially used similarly to a VLookup.
Currently My code is thus:
Private Sub UpdateBasic_Click()
Dim bucket As String
DoCmd.OpenQuery "test", acViewNormal, acReadOnly
'this line is meant to record the result of the query into a variable. It is not working but I haven’t found the right command to get it to pick up the data yet.
bucket = A1
DoCmd.Close acQuery, "test", acSaveNo
DoCmd.OpenForm "BasicData", acNormal, , , acFormEdit, acWindowNormal, "Global_ID = 'sdkfa'"
'this line is meant to update the value of the field on the form.
DoCmd.SetProperty testfield, acPropertyValue, bucket
End Sub
I am having no luck getting the SetProperty command to work at all. It is consistently telling me I have a data type mismatch regardless of whether I try to give it a variable like bucket or a value like 10. Error message is as follows:
Run-time error ‘2948’:
An Expression you entered is the wrong data type for one of the arguments.
Any and all help would be appreciated.
If you're simply trying to assign the result of a query to the value of a field in a form, I'd recommend a DLookup() function. You can use it like this (assuming the form's control is a textbox):
Me.TextBox.Value = DLookup("FieldName", "QueryName")
More elaborate solutions would involve recordsets, etc. but if you're looking for a quick, simple solution this should do just fine. Hope that helps!
In a data validation form, I have a subroutine checking previously-entered data on a LostFocus event by ensuring that the release time (TimeReleased in table; Me.txtTimeReleased on form) is after the capture time (ObservationTime in table; Me.txtObservationTime on form). I'm using LostFocus rather than BeforeUpdate because the data were bulk-imported into the db and are now being error-checked.
My users keep getting a compile error (Compile Error: method or data member not found) upon tabbing out of the field this sub is attached to but I cannot reproduce the problem locally. The error occurs on this line:
If (Me.txtTimeReleased) <= (Me.ObservationTime) Then
and the part highlighted is '.txtTimeReleased'
Full code block:
Private Sub txtTimeReleased_LostFocus()
Dim badData As Variant
Dim resp As Variant
'Also check that time released is after time captured
If Not IsNull(Me.txtObservationTime) And Not IsNull(Me.txtTimeReleased) Then
If (Me.txtTimeReleased) <= (Me.ObservationTime) Then
resp = MsgBox("Release time must be after capture time." & vbCrLf & "Please double check this field's value: is it correct?", _
vbYesNo + vbExclamation + vbDefaultButton2, "Release Time Before Capture Time")
If resp <> vbYes Then badData = True
End If
End If
If badData = True Then
Me.cmbTaxonId.SetFocus 'set focus away so can set focus back
With Me.txtTimeReleased
.SetFocus
.SelStart = 0
.SelLength = 10
End With
End If
End Sub
Other things to note:
Both the table field and form control are formatted as 'Short Time' (24-hour time)
There is an input mask on that form control for 24-hour time; I use input masks very rarely and thus aren't familiar with them--perhaps the input mask could be causing the problem?
There are similar LostFocus subs on most of the other controls which do not produce this (or any other) error
Things I've tried:
Checking spelling
Fully decompling and recompiling the code: starting with shift, compact and repair with shift, open with /decompile flag while holding shift, compact and repair with shift, re-open with shift, and finally compile (without error)
Replacing the form in their database with one that works fine for me on the same data
Google
Things that seem odd to me:
I can't reproduce the error locally.
The error is triggering on the second instance of
Me.txtTimeReleased rather than the first: it has already passed a Not
IsNull(Me.txtTimeReleased) check.
The fact that it's a compile error: could that be masking something else?
Thanks for your time, and please let me know if there's any additional information that would be useful. Any thoughts are most welcome!
You checked for Null txtObservationTime and txtTimeReleased, but compare then txtTimeReleased and ObservationTime. Maybe solution is:
If Not IsNull(Me.txtObservationTime) And Not IsNull(Me.txtTimeReleased) Then
If (Me.txtTimeReleased) <= (Me.txtObservationTime) Then
Opening the .mdb with the /decompile flag is one of the first things I would have suggested, but you said you already tried that.
Here's another undocumented trick to deal with "hidden" compile problems that get baked in by VBA behind the scenes:
First, make a backup copy of your .mdb just to be safe (this is, after all, an undocumented technique).
Then, save your form to a text file using SaveAsText:
SaveAsText acForm, "MyFormName", "C:\MyFormName.txt"
Finally, re-load your form using the equally undocumented LoadFromText:
LoadFromText acForm, "MyFormName", "C:\MyFormName.txt"
Compile.
Compact.
Repair.
Hope for the best.
Good luck.
I suggest you use variables:
intThat = Me.txtTimeReleased
If intThis <= intThat Then
Try using ! instead of a dot:
intThat = Me!txtTimeReleased
If intThis <= intThat Then
And now, the answer that worked for me last week:
Comment out the offending line.
Run a compile that is successful.
Restore the offending line.
The compile may work now. Don't ask me why.
Not sure this is possible, but it seems like it should be doable.... it is 2013 after all! And some forum posts I found suggest it is, but I have not been successful in getting it to work...
I have an Access 2010 db with a macro that downloads files from 3 different web sites and then proceeds to import the data and process it. It runs for 1hr and 17 mins.
I want to schedule this macro to run at 4am so it is all done and dusted by coffee time and work start 8am... So I created a VBScript to run this, which will then be placed into the Task Scheduler for the desired time.
It is a single user DB, my use only on my PC.
I have done some research but I cannot seem to get this working. Here's what I have so far:
Macro inside "Main" module in Access 2010 inside of "Pricing Model.accdb":
Public Sub Download_And_Import()
ProcStep = ""
ExecStep = 1
DoCmd.SetWarnings False
'Empty the Execution Progress table
DoCmd.RunSQL "DELETE * FROM EXECUTION_PROGRESS"
Call Update_EXECUTION_PROGRESS(Format(Now(), "YYYY/MM/DD HH:MM:SS"), ExecStep, "Starting Download_Files Main Procedure...")
Call Download_Files.Download_Files
Call Update_EXECUTION_PROGRESS(Format(Now(), "YYYY/MM/DD HH:MM:SS"), ExecStep, "Finished Download_Files Main Procedure...")
Call Update_EXECUTION_PROGRESS(Format(Now(), "YYYY/MM/DD HH:MM:SS"), ExecStep, "Starting Import_Files Main Procedure...")
Call Import_Files.Import_Files
Call Update_EXECUTION_PROGRESS(Format(Now(), "YYYY/MM/DD HH:MM:SS"), ExecStep, "Finished Import_Files Main Procedure, closing application now...")
DoCmd.SetWarnings True
End Sub
I then created the following VBScript to run Access VBA Macro externally:
dim accessApp
set accessApp = createObject("Access.Application")
accessApp.OpenCurrentDataBase("G:\Pricing DB\Pricing Model.accdb")
accessApp.Run "Download_And_Import"
accessApp.Quit
set accessApp = nothing
I get the message "Illegal function call, Line 4" which is the step:
accessApp.Run "Download_And_Import"
Any ideas / help is highly appreciated! Thanks in advance!
M
I don't see anything wrong with the VBScript itself. I copied your code, changed the db file name and procedure name, and it ran without error. So my guess is the VBScript error "bubbles up" from Access when it tries to run the procedure.
Open Pricing Model.accdb in Access, go to the Immediate window (Ctrl+g), type in the following line and press Enter
Application.Run "Download_And_Import"
If that throws an error you surely have a problem in that procedure. If it doesn't throw an error, you could still have trouble running it from a scheduled task if the procedure requires Windows permissions and you haven't set the task to run under your user account.
If you need to troubleshoot the procedure, first add Option Explicit to the module's Declarations section. Then run Debug->Compile from the VB Editor's main menu. Fix anything the compiler complains about. Repeat until the code compiles without error.
Disable DoCmd.SetWarnings False during troubleshooting because it suppresses information. Consider whether substituting the DAO Database.Execute method for DoCmd.RunSQL will allow you to avoid turning SetWarnings off at all.
You could try including the ProjectName:
accessApp.Run "[Pricing Model].Download_And_Import"
The project-name defaults to the database name, and square-brackets are needed because of the spaces.
This shouldn't be necessary, because your Sub is Public, but worth a try.
I ran into the same (msg) issue the script was OK! Problem was i was testing the script with the database opened as I was in development mode, as soon i closed the Database the script worked well.Close the database before testing the script.
I am writing a VBA function to import data from one table to another in Access. The table I'm importing into has more strict data constraints (i.e. types, size etc.), so I'm expecting a lot of errors.
Rather than sift through every VBA error that comes up, I want my recordset loop to skip the entire current record and make a note of it in a separate table whenever it runs into an error. So every other line I've inserted On Error GoTo RecordError. But for some reason it's not handling every error. My code just breaks and tells me what the error is. I have the "Break on Unhandled Exceptions" option checked already.
Here's a screenshot that should explain it.
Why would it be breaking on the line immediately following an Error handler?
I think you're not understanding how VB(A) error handling works. Follow these principles:
An On Error... statement only applies to the routine (Sub or Function) in which it appears (though it will also catch errors that "bubble up" from routines that are called from within the routine in which you use it).
On Error sets a state. That is, Once you issue an On Error... it remains in force for the rest of the routine, unless superceded by a new On Error....
There are four forms of On Error...:
On Error GoTo <label>: <label> must be defined in the same routine, by writing the label name immediately followed by a colon (:) on a line by itself.
On Error Resume: immediately retries the error-throwing statement. Hardly ever used, since it's potentially infinite.
On Error Resume Next: ignores the error & continues. Sometimes useful at the end of routines for cleanup (for instance, if you want to Close a Recordset that may or may not be open). Alternatively, this form can also be used if you check the Err object immediately after any potentially error-throwing line (if Err.Number is zero (0), the statement succeeded without throwing an error). This is way too much work for most situations.
On Error GoTo 0: turns off error handling.
Given this, it's usual to place the On Error... statement immediately followng the routine's declaration (the Sub or Function statement), though some people put their Dim statements in between. If you want to temporarily change the manner of error handling within a routine, put the "new" one right before the code to which it is to apply, and (if used), the "revert" (reissuing the original), right after.
Even given all that, I have no idea why it would break on the error-throwing line when "Break on Unhandled Errors" is selected, unless you've managed to confuse it so much that it thinks there's no active error handling (and I'd be surprised if it compiled if that were the case).
Note that David Heffernan gave you the essential part of this in his answer, and it was here before mine....
The reason it is not working is because you cannot use On Error Goto ... within an error handler.
see http://www.cpearson.com/excel/errorhandling.htm
you cannot use On Error to skip a few lines, instead on error should go to a error handler which then resume's to the desired next line (in your example you could probably get away with one error handler which contains a resume next which will take you back to the next field).
thanks to Tim Williams on this question: The second of 2 'On Error goto ' statements gets ignored
and BTW ParseInt on a ZIP will destroy zip codes that begin with a 0, zipcodes should probably be treated as text.
You need to place the On Error line before the code whose errors you wish to handle.
What's more you only need to have one On Error line. The error handler then stays active until the subroutine exits or you execute another On Error statement.
Error handling with VBA is a real PITA. I'd propose you to have a look at this answer to the 'MS-Access, VBA and error handling' question, and have it adapted to your own situation. You can easily write down some code that will store all your error messages in a table, building a de facto error reporting system.
Setting the debug mode to 'break on all errors' will make the program execution stop at the line that causes an error even when the error handler has been correctly written. This can be confusing as it appears that error handling is not working.
Nobody has really answered your question.
Say your code is something like this (a skeletal framework):
Public Sub MySub()
On Error GoTo errHandler
Dim rs As DAO.Recordset
Set rs = CurrentDB.OpenRecords([SQL SELECT])
If rs.RecordCount >0 Then
rs.MoveFirst
Do Until rs.EOF
[do whatever that produces the error]
errSkipToNext:
rs.MoveNext
Loop
End If
exitRoutine:
If Not (rs Is Nothing) Then
rs.Close
Set rs = Nothing
Exit Sub
errHandler:
Select Case Err.Number
Case X, Y, Z ' where these are error numbers you want to ignore
Err.Clear
' do whatever it is you need to do in order to record the offending row
Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
GoTo errSkipToNext
Case Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error!"
Resume exitRoutine
End Select
End Sub
In this code, you use a SELECT CASE in your error handler to decide which errors you want to ignore. In my code framework above, I listed the error numbers as X, Y, Z, but you'd replace that with the real error numbers you want to ignore, instead.
You don't want to ignore every single error because you might end up ignoring important errors elsewhere in your subroutine. If you don't want to figure out what the limited number of errors you want to ignore happen to be, I would suggest that you set a flag at the beginning of the code block that produces the errors you want to ignore, then use an `If bolErrorInCodeBlockToIgnore Then to decide if you're ignoring all errors or not. Something like this:
Public Sub MySub()
On Error GoTo errHandler
Dim rs As DAO.Recordset
Dim bolErrorInCodeBlockToIgnore As Boolean
Set rs = CurrentDB.OpenRecords([SQL SELECT])
If rs.RecordCount >0 Then
rs.MoveFirst
Do Until rs.EOF
bolErrorInCodeBlockToIgnore = True
[do whatever that produces the error]
errSkipToNext:
rs.MoveNext
Loop
End If
exitRoutine:
If Not (rs Is Nothing) Then
rs.Close
Set rs = Nothing
Exit Sub
errHandler:
If bolErrorInCodeBlockToIgnore Then
Err.Clear
' do whatever it is you need to do in order to record the offending row
Call RecordError(rs!PK, Err.Number) ' PK is a field that identifies the bad record
bolErrorInCodeBlockToIgnore = False
GoTo errSkipToNext
Else
MsgBox Err.Number & ": " & Err.Description, vbExclamation, _
"Error!"
Resume exitRoutine
End If
End Sub
I would much prefer the first, as I'm a firm believer in only ignoring known errors, not any old error that happens. But it might be quite difficult to come up with tests that will produce all the possible errors you want to ignore.
I have seen error handling fail too. Here is one example.
Public Function Have(ByVal item As Variant) As Boolean
'Have = Have data. Simplifies handling nulls and empty strings in validation code
On Error GoTo Procerr
If IsNull(item) Then
Have = False
**ElseIf Len(Trim(item)) = 0 Then 'Faster than Item <> ""**
Have = False
ElseIf item = 0 Then
Have = False
Else
Have = True
End If
exitproc:
Exit Function
Procerr:
'Errors sometimes occur if an unbound control is referenced
Have = False
End Function
The code sometimes fails on the line flagged with **. Here is the error message.
Note that the error handler has failed. In this case, the form that called the code returned had its recordsource set on the fly to an empty recordset, hence the fields on the screen are not visible. The form is a continuous form, so records and fields are not visible when the form is loaded with an empty recordset. The have() function is not directly called by my code, but somehow seems to be triggered by the me.requery method. The have() has been called hundreds of millions of times in my code but this is the only instance that causes it to fail and the error handler is not involked.
To Lance Roberts re original question. utf-8 unicode can sometimes play havoc with ms-access as it seems to be allow data to be confused for instruction codes (my guess). utf-8 can get into your data if data was originally loaded from a text file. utf-8 with a byte order mark (BoM) is particularly nasty. When you run some procedure that works with the data, strange errors can occur and it may look like your file has become corrupt. In other cases, text handling functions give wrong answers, e.g. Mid() will see the BOM and if you specify a starting point will start at the BOM, but Len() ignores the BOM. I am speculating that if you have this issue, then ms-access may not handle errors correctly. I have had similar issues importing data and importing utf-8 as ANSI was the cause. Note that utf-8 and ANSI are identical most of the time for plain English data so your errors may not be on every line. My errors were mostly with time-date fields. Try exporting the data first and then forcing it to be ANSI and remove any BoM and and reimporting it.