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.
Related
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.
I don't know what may be wrong but that's what I get when I try to start the program:
The type initializer for MySql.Data.MySqlClient.Replication.ReplicationManager threw an exception.
The problem appears to come from conn.Open()
This is part of my code:
Imports MySql.Data.MySqlClient
Public Class Main
Dim conn As MySqlConnection
Private Sub Main_Load(sender As Object, e As EventArgs) Handles Me.Load
conn = New MySqlConnection()
conn.ConnectionString = "server='127.0.0.1';
user id='root';
Password='test';
database='snipper'"
Try
conn.Open()
Catch myerror As MySqlException
End Try
End Sub
End Class
I guess the problem is with your connection string
For instance your connection string should be like this
Server=myServerAddress; Database=myDataBase; Uid=myUsername; Pwd=myPassword;
To know more Click Here..!!!
Hope this helps
Happy Coding
Just found the problem... I hadn't enable "SQL Server Debugging". It worked well when I did. Thanks everyone!
I had the same error, but a different solution. First I tried the enable "SQL Server Debugging", but that didn't change anything (I still don't know why this setting would make a difference).
The solution for me was the user rights on the server. The application runs with the Task Scheduler under a user account. Only the domain of this user account was changed. So the MySQL Connection didn't have enough rights.
Are you sure with that connection string?! Try to change it to:
conn.ConnectionString = "server=127.0.0.1;uid=root;pwd=test;database=snipper;"
Follow this reference:
http://dev.mysql.com/doc/refman/5.0/en/connector-net-programming-connecting-connection-string.html
It could be a bad reference to the DLL. Make sure the dll is the right verson for the .net you're using. I also had the same issue and found that in the app.config file i was defining log4net configurations for my logger and that was the issue. i had to define a different config file for log4net so that mysql would work.
I had to rebuild a machine here and thought I'd just redo my web site in the process. I decided to go with mvc 3 but still use mysql on the back end.
I essentially copied and pasted all of my old code for the sql connection to return results from a mysql stored procedure and it's not working at all. I then tried creating a simple insert sproc and it doesn't work either. If I use in-line sql on my MySqlCommand, it works fine however (both selecting and inserting). I'm thinking that with .net 4.0 they changed something on the CommandType.StoredProcedure...but I can't say for sure.
When I put a breakpoint on my command call to the actual sproc, it doesn't show anything, nor does it actually do anything. I've called the sprocs from the CLI and they're working just as they should. Back to what I was saying, I'm guessing that with .net 4, it doesn't use the "Call" command any more. Anyone run into this issue? If so, do you have a solution? Is there anyway to import the System.Data 2.0 dll into a .net 4.0 project to verify what I'm thinking?
here's some code on my database layer:
public static BuyCollectionModel GrabBuyData(GridSettings gridSettings)
{
int totalRows = 0;
BuyCollectionModel buys = new BuyCollectionModel();
using (MySqlConnection myConnection = new MySqlConnection(AppConfig.Connection)) {
//string sql = "SELECT 100 as totalrows, c.* FROM cBuys as c";
//MySqlCommand myCommand = new MySqlCommand(sql, myConnection);
MySqlCommand myCommand = new MySqlCommand("usp_GetBuys", myConnection);
myCommand.CommandType = CommandType.StoredProcedure;
myCommand.Parameters.AddWithValue("#startrowvar", gridSettings.PageIndex);
myCommand.Parameters.AddWithValue("#endrowvar", gridSettings.PageSize);
myCommand.Parameters.AddWithValue("#sortcolvar", gridSettings.SortColumn);
myCommand.Parameters.AddWithValue("#sortordervar", gridSettings.SortOrder);
myConnection.Open();
using (MySqlDataReader myReader = myCommand.ExecuteReader())
{
while (myReader.Read())
{
buys.Add(FillBuys(myReader, out totalRows));
}
}
myConnection.Close();
}
buys.TotalCount = totalRows;
return buys;
}
as mentioned above, I've also tried creating a simple insert sproc that works fine from the CLI, but when I call it from code using ExecuteNonQuery(), it does nothing...
Try reverting to an older version of the connector. One that works for me is 6.3.4. Also, make sure you are using the exact same version on the server as on your dev workstation.
Is there anyway to import the System.Data 2.0 dll into a .net 4.0 project.....
If you are running visual studio, then click on Project-> Add Reference -> Browse and find there your dlls you want to add to project.
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.