I am writing a code in Access VBA. I am facing an issue when using a recordset. Here is what I have in the first lines of my code:
Dim rst As Recordset
Dim sql as String
sql = "Select ........"
Set rst = CurrentDb.OpenRecordset(sql, dbReadOnly)
The program fails in the second line " set rst= .....". I added the following references:
Visual Basic for Applications,
Microsoft Access 12.0 Object library,
OLE automation,
Microsoft ActiveX Data Objects 2.8 Library
But the program still fails in the second line. Is there anything else I should do???
Thanks,
Currentdb is DAO code but you state you have an ADO reference. Remove the ADO reference and add the Microsoft Office 12.0 Access database engine Object Library.
If this were Access 2000, 2002 or 2003 I'd suggest adding the Microsoft DAO 3.6 Object Library.
Related
I have an application developed on Microsoft Access (.accdb) to manage stocks and i like to develop an module to use a data collector that runs a windows CE 5.0.
So I started to develop in .net (VS 2008) the screen to make the stocks movimentation like expedition. At the moment that I try to connect to database the VS give me an error telling me that is not possible make the connection, but when I test the connection, the connection is sucessfull.
I just want make simple operations like select and update the values in database.
Is there any way to make the connection?
I found something, but all of those solutions use SQL / SQLCe.
The code that I Try
Imports System.Data.OleDb
Public Class Form1
Public OleDb As OleDbConnection
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
Dim dbComm As OleDbCommand = OleDb.CreateCommand()
dbComm.CommandText = "SELECT * FROM CLIENTE WHERE CLI_ID = #P0"
dbComm.Parameters.AddWithValue("#P0", TextBox1.Text)
Dim dr As OleDbDataReader = dbComm.ExecuteReader()
dr.Read()
Label2.Text = dr("CLI_NOME").ToString()
End Sub
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
OleDb = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\db.accdb;")
OleDb.Open()
End Sub
End Class
Give me an error on the first line after I put the Imports System.Data.OleDb
Error: Warning 1 Namespace or type specified in the Imports 'System.Data.OleDb' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
So your trying to run this code on Windows CE 5.0, presumably using .Net Compact Framework 3.5 ?
Are you sure that the 'System.Data.OleDb' namespace is supported on that platform?
Are you sure that the 'Microsoft.ACE.OLEDB.12.0' driver is available on that platform?
I don't think they are supported or available for this platform. I would say your best bet is to architect the system such that, you run a browser type application on the Windows CE device, and connect to a remote web server, and have that server do the read/writing to the database.
Currently I'm working on an Access Database Application which was using ODBCDirect. After upgrading to Access 2010 I receive an error message that told me that ODBCDirect isn't supported anymore and that I have to change from the DAO to ADO in the corresponding source code parts each time I'm running the application.
I found out that the origin of this error message was the source code that was responsible for the database connection which was making use of ODBCDirect.
I followed the tutorials about ADODB.Connection objects and the opening of them. I changed this code to the following simple code by using the ADODB.Connection object.
Now I'm receiving the new error message "(-2147467259) operation is not supported for this type of object".
I found out that the place where I was using the Open function of the ADODB.Connection Object is causing the new error message:
Global conWork As ADODB.Connection
...
Set conWork = New ADODB.Connection
...
conWork.ConnectionString = "ODBC;DRIVER={SQL Server};SERVER=someServer.x.y.z;Provider=Microsoft.ACE.OLEDB.12.0;UserID=user;Password=pw;Data Source=someServer.x.y.z; Trusted_Connection=yes;"
...
conWork.Open //...causes the error msg "OPERATION IS NOT SUPPORTED FOR THIS TYPE OF OBJECT"
In the vba editor I have the Microsoft ADO 2.8 Library and the Microsoft ADO 2.8 RecordSet Library selected in the references-settings.
I'm unsure why your attempt fails, but there are several issues which look suspicious to me.
Don't include ODBC; in your ADO connection string. Including that piece triggers a run-time error in my tests.
I don't believe you should include both DRIVER={SQL Server} and Provider=Microsoft.ACE.OLEDB.12.0 in your connection string.
Including both UserID=user;Password=pw and Trusted_Connection=yes seems wrong. Choose one or the other, not both.
You must do Set conWork = New ADODB.Connection before you set its ConnectionString and call Open. I can't tell whether your full code does that; it should.
I don't think you need the recordset library reference, but don't know whether including it contributes to the problem.
Maybe you would be better off to start from known-working ADO connection code. This code works in Access 2010 with the Microsoft ActiveX Data Objects 2.8 Library reference and successfully connects to my local SQL Server.
Dim conWork As ADODB.Connection
Dim strConnect As String
strConnect = "DRIVER={SQL Server};SERVER=HP64\SQLEXPRESS;Trusted_Connection=Yes;DATABASE=testbed"
Set conWork = New ADODB.Connection
conWork.ConnectionString = strConnect
conWork.Open
You can find more information regarding connection strings for SQL Server at ConnectionStrings.com.
I have an Access app, developed in Access 2013 in multi-user env, uses Excel automation to export and format an Excel file.
The normal Office/Excel 2013 (15.0) references have been made and all works well on Office 2013 machines. Does not play nicely on 2010 machines.
Using a 2010 machine, I replaced the 15.0 references with 14.0 references, and the app is happy on 2010 and 2013 machines. Upon next edit/update on my 2013 machine the 15.0 references return.
Any suggestions to more conveniently develop/operate in this multi-version environment?
Thanks!
The overall solution to this issue is to use late binding. The downsides to late binding are
Dim xlApp As Object means that we don't get any IntelliSense for xlApp, and
related constants like xlEdgeTop are not defined without the associated Reference
These issues can be mitigated by using conditional compilation in the VBA project. For development, add the required Reference to the project and define a conditional compilation argument
which you can use in your code like this
Option Compare Database
Option Explicit
Public Sub WorkWithExcel()
#If LateBinding Then
Dim xlApp As Object
Set xlApp = CreateObject("Excel.Application")
#Else
Dim xlApp As Excel.Application
Set xlApp = New Excel.Application
#End If
Debug.Print xlEdgeTop
End Sub
To avoid clutter, I would be inclined to keep the constants in a separate Module like this
Option Compare Database
Option Explicit
#If LateBinding Then
Public Const xlEdgeTop = 8
#End If
When the code tweaking is complete, remove the Reference, set the LateBinding argument to "True" (LateBinding = -1) and compile the project. Add any constants you've missed (there always seems to be one or two) and when it compiles without the Reference you should be good to deploy.
For the next development session, set LateBinding back to "False" (LateBinding = 0) and add the Reference back in.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
So I have an MS Access application originally in a 2002-2003 format. Developed on a production network image, and when the image pushed the office upgrade, it became office 2007. So this is used in a very non traditional way...reps take it with them on company laptops enter data, and it automates complex ppt presentations, and excel worksheet for them (they love it....they need it). Data is not held in this like a database repository, just long enough to produce the automation they need and it works....saves them time. So Access is limited, and in the use case, really limited since i am using it in a way it certainly wasn't intended to be used. I get that, but like I said so far, its working pretty well.....
The one bump I have run into is if someone has to use another computer for whatever reason (doesn't happen often but it got me thinking), and say they have a version of 2002-2003 access, the tool will run, but once we get to the code routines/modules for ppt & outlook, the object libraries show MISSING because working on this tool seems to automatically cause the libraries to go up to the next available version, but not down to find the version.....
so originally when I made this....it used MS PowerPoint 11.0, and MS Outlook 11.0, and then when I had to start working in 2007 it became 12.0 for both, some instances I see it bumped up to 14.0, and none of the ups are a problem, but now since I have an image with Office 2007 out, and new files version I try to give them has the libraries defaulted to 12.0 and if they run into a scenario where they would take the file on a disc and use it on a computer that has office 2003, those libraries just come up missing and it doesn't recognize the appropriate 11.0 object libraries anymore.
So finally my question....any suggesions (save the obvious and build a real app...lol...would love to....no $) to handling this? Is there code that can/will evaluate what libraries need to be set on opening the file using vba? Is that possible?
There is Remove Method which you could use to remove a reference, then AddFromFile Method or AddFromGuid Method to add a reference.
The AddFromFile approach was offered in answers to this recent StackOverflow question: Add references programatically However, make sure to read Tony's answer ... if you're distributing your application as an MDE, you're SOL.
Consider switching to late binding for your PowerPoint and Outlook stuff. That way you won't have to fiddle with references (no reference required for late binding). A drawback from late binding is you lose the benefit of IntelliSense during development. However, you can develop with early binding, then switch to late binding for deployment. Substitute the values where you used any named constants from the referenced library ... debug will highlight any you overlook.
A frequent counter-argument is that late binding imposes a "performance penalty". However, I've yet to encounter a use case where the "slow-down" was large enough to be noticeable by a human observer.
In any case I've been using late binding for years specifically to avoid the type of deployment issue you're struggling with now.
Edit: Here is an example which uses the Excel type library. I have it set to use early binding. To convert it to late binding, comment out the declarations under '* early binding ... , and uncomment those under '* late binding ...
Also notice the 2 lines which include the named constant, xlAutomatic.
Public Sub EarlyVsLateBinding()
Dim strFullPath As String
'* early binding requires reference to Excel type library *'
Dim objExcel As Excel.Application
Set objExcel = New Excel.Application
Dim objBook As Excel.Workbook
Dim objSheet As Excel.Worksheet
'* late binding; no reference required *'
' Dim objExcel As Object '
' Dim objBook As Object '
' Dim objSheet As Object '
' Set objExcel = CreateObject("Excel.Application") '
strFullPath = CurrentProject.Path & Chr(92) & "foo.xls"
Set objBook = objExcel.Workbooks.Open(strFullPath)
Set objSheet = objBook.Worksheets("bar")
objSheet.Range("B1").Select
With objExcel.Selection.Font
.Name = "Arial"
.FontStyle = "Regular"
.Size = 10
.ColorIndex = xlAutomatic 'named constant available with reference set '
'.ColorIndex = -4105 'substitute xlAutomatic value so we drop reference
End With
objBook.Close SaveChanges:=True
objExcel.Quit
Set objSheet = Nothing
Set objBook = Nothing
Set objExcel = Nothing
End Sub
I like the subform/subreport control in Access, and I want to put an instantce of the control on my VB6 form.
I reference the msacc.olb in my VB6 project, and put the following codes in my form module.
Private Sub Form_Load()
Dim aa As Access.SubForm
Set aa = Me.Controls.Add("Access.SubForm", "sf1")
aa.Name = "vvvddvv"
aa.Visible = True
Debug.Print aa.Name, aa.Left
End Sub
I get a Run-time Error '711': Invalid Class String. Looking For Object with ProgId:Access.SubForm.
How can I fix it? Or is there other approach which I can use the Access' SubForm control in a Vb6 form?
You can't do that - Access objects are not usable outside of MS Access environment.
You can control Access via OLE/COM but that works by starting up MS Access in the background so you can work with the Access objects.
It's been a while since I've done this, but I recall having to create a user control in VB6 and then use a repeater control to simulate an Access continuous subform.