I've added an access db to my project as a datasource. So I get the automatically generated tableadapters class and therefore, access to the table adapter instance which includes the connection string. I'm using this to open a connection to my db so I can first, delete some records, and then replace them with new records.
The queries seem to work because the .executenonquery does return the rows affected. I even tried a delete * command to be sure. But, when I open the database everything is the same.
I had some ideas as to why. I thought the connection string returned by the tableadapter might be goofy because it contains a generic pointer to the project's data directory.
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\DupeMDB.mdb;Persist Security Info=True
I also thought maybe I had a problem with the Build Action or the Copy to Output Directory. I really don't understand the mechanics behind these two things. I think maybe the copy to output directory thing might be the culprit.
Here's me goal. I want to deploy this project to my secretary so she can use the program to deal with a duplicate record list etc. The data has to go with the program. I want to package this .mdf file with the deployment and get it back from her when she's done with it. I am so close to the end here (writing back to the table). Does anyone know why the table won't update?
Dim Connector As DupeTblTableAdapter = New DupeTblTableAdapter
Dim Conn As New System.Data.OleDb.OleDbConnection
Conn = Connector.Connection
Conn.ConnectionString = Connector.Connection.ConnectionString
MsgBox(Conn.ConnectionString)
Dim Comm As System.Data.OleDb.OleDbCommand
Conn.Open()
For Each DR In DeleteRecords
Comm = New System.Data.OleDb.OleDbCommand($"DELETE from DupeTbl where DupeTbl.CUST_NO={DR.ToString}", Conn) '
Dim aff As Integer = Comm.ExecuteNonQuery
'MsgBox(aff)
Comm = Nothing
Next
For Each RR In ReplaceRecords
Comm = New System.Data.OleDb.OleDbCommand($"INSERT INTO DupeTbl ( CUST_NO, PREDIR, POSTDIR, SUFFIX, CUSTSIZE, AddFlag, IgnoreRecord ) VALUES ({RR.Cust_No}, '{RR.PreDir}', '{RR.PostDir}', '{RR.Suffix}', {RR.Size}, {RR.AddFlag}, {RR.Ignore});", Conn)
Comm.ExecuteNonQuery()
Comm = Nothing
Next
Conn.Close()
The issue in such cases is usually the working database being overwritten on each build. When adding a local data file to your project, it is added as a source file in the project folder. By default, the Copy to Output Directory property is set to Copy Always. That means that every time you build your project, which will happen each time you make a code change and run the project by default, the source file will be copied over the top of the working database in the output folder, thus wiping out any changes you made while debugging. To prevent this, change that property to Copy if Newer, which means that the working database will only be overwritten if you make a change to the source database, e.g. modify the schema.
Dim Connector As DupeTblTableAdapter = New DupeTblTableAdapter
Dim Conn As New System.Data.OleDb.OleDbConnection
Conn = Connector.Connection
Conn.ConnectionString = Connector.Connection.ConnectionString
MsgBox(Conn.ConnectionString)
Dim Comm As System.Data.OleDb.OleDbCommand
Conn.Open()
For Each UR In UpdateRecords
Comm = New System.Data.OleDb.OleDbCommand($"UPDATE DupeTbl SET CUST_NO = <NewValue>, PREDIR = <NewValue, POSTDIR = <NewValue> etc. where DupeTbl.CUST_NO={DR.ToString}", Conn) '
Dim aff As Integer = Comm.ExecuteNonQuery
'MsgBox(aff)
Comm = Nothing
Next
Conn.Close()
Related
Dim cat As New Catalog()
Dim con As New OleDbConnection()
Dim cmd As New OleDbCommand
Dim ds1 As New DataSet
Dim conn As ADODB.Connection
' Open the Access database.
conn = New Connection
conn.ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;" &
"Data Source=" + openExcel + "\Test" + ".mdb; Persist Security Info=False"
con.ConnectionString =
"Provider=Microsoft.Jet.OLEDB.4.0;" &
"Data Source=" + openExcel + "\Test" + ".mdb; Persist Security Info=False"
conn.Open()
xlWorkSheet1.Columns(5).Insert
Dim cellValue As String = ""
Dim newValue As String = ""
Dim sh1 As String = ""
Dim qty As String = ""
Dim matchText As String = ""
Dim sql As String = ""
con.Open()
sh1 = LTrim$(xlWorkSheet1.Cells(i, 1).Text)
sql = "SELECT Num_ber, Q_ty FROM good WHERE Na_me LIKE 'staff%' And Ty_pe = 'ORD'"
Dim cmd As New OleDbCommand(sql, con)
Dim myReader As OleDbDataReader = cmd.ExecuteReader()
conn.Execute(sql)
myReader = cmd.ExecuteReader() ' HERE'S THE PROBLEM
xlWorkSheet1.Cells(1, 5) = myReader.GetString(0)
xlWorkSheet1.Cells(1, 11) = myReader.GetString(1)
myReader.Close()
conn.Close()
conn = Nothing
**I wanted to retrieve a specific value from mdb and then write it to excel.
Here's my code, I got this error so many times and I can't find it out. Can anybody help me? Thanks.**
[1]: https://i.stack.imgur.com/6Fuvg.png
Ok, you first have to decide when usng .net what "provider" you are going to use, AND THEN decide what kind of data objects you want to use.
You can use a oracle provider, a sql server provider, or in this case, since we using Access, then we can use EITHER oleDB, or ODBC. Either choice is fine. Most use oleDB providers for Access, but often ODBC is a good choice, especially if down the road you plane to swap out Access for say SQL server.
What the above means in plain English?
You don't want to adopt the external ADODB code and library. That code is NOT .net, and thus you REALLY but REALLY do not want to write your .net code that way. ADODB was written LONG before .net, and is what we call un-managed code (non .net). I strong, but strong suggest you do NOT add a reference to ADODB to your project, and I beyond strong recommend you avoid introduction of a non .net library for doing this!!! We certainly can adopt the oleDB provider in .net, but we will NOT have a direct reference to JET/ACE (the access database engine) in our applcation. As noted, there are some exceptions to this suggesting, but they don't apply to you and here.
Next up:
The design pattern in .net is to create the connection, get the data, and CLOSE the connection. This "pattern" will then be 100% sure that the data base is always closed, and you NEVER have to worry about if the connection is open, closed, or even if you forgot to close the connection!!! So, do this correct, and some "open" connection will never bite you, or will you have to worry about this issue.
You can in some operations keep the connection open for performance, but lets learn to walk before we run so to speak.
next up:
We certainly do NOT want to place and have connection strings all over in our code. Not only is this going to wear out your keyboard, but if you ever need to change the connection, then you going to have to hunt down all that code.
Best to let Visual Studio save that connection in ONE location, and MORE important MANAGE this for you!!!
Next up:
Do you ONLY need to work with mdb files, or do you plan/need to work with accDB files? This is a HUGE issue, and one that you cannot ignore.
next up:
Are you going to use the x32 bit version of the Access database system, or the x64 bit version?
Since your example posted code uses JET (access data engine for mdb files ONLY x32 bit version)?
Then this ALSO means you MUST (and I repeat MUST) force your .net project to run as x32 bits. You cannot use "any cpu", and you cannot use x64 bits, you MUST choose x86 bit size for your .net project. Failure to do so will result in the project not working.
Ok, with the above information?
First up, force/set/be 100% sure your project is set to run as x32 bits.
That setting is this one:
and remove the reference you have to ADO if you created one.
Ok,
next up:
Create the connection to the database.
Project ->properties.
This here:
And then:
and then
Now, you can browse, and select the access mdb file.
But, you MUST not skip the next step - you have to choose JET (older, mdb files), or choose the newer ACE (for accDB format files).
So, this:
now this:
As noted, you choose JET or ACE here.
now, we have this and you can use test connection.
BUT BE VERY careful!!!!
If you are using vs2022, then keep in mind vs2022 is the FIRST version of VS that is now x64 bits. As a result, vs can't pass the test connection!!! Your connection is in fact ok, but will fail with vs2022.
If you using a previous version of VS (before 2022), then the test connection button should work. and you see this:
Ok, now that we have a valid working conneciton setup, we can now write code, and we will NOT use ADODB!!!!
The typical code pattern to read and load a data table (like a access VBA recordset) will be like this:
Now, I became RATHER tired of writing that same using block over and over. So, in a global module, I have this code now:
Public Function MyRst(strSQL As String) As DataTable
Dim rstData As New DataTable
Using conn As New OleDbConnection(My.Settings.AccessDB)
Using cmdSQL As New OleDbCommand(strSQL, conn)
conn.Open()
rstData.Load(cmdSQL.ExecuteReader)
End Using
End Using
Return rstData
End Function
So, now with the above handy dandy helper routine?
Your code becomes this:
Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
Dim Sql As String =
"SELECT Num_ber, Q_ty FROM good WHERE Na_me LIKE 'staff%' And Ty_pe = 'ORD'"
Dim rstData As DataTable = MyRst(Sql)
Debug.Print("Na_me is " & rstData.Rows(0).Item("Na_me"))
End Sub
Or, display all return rows from that data table
Debug.Print("Na_me is " & rstData.Rows(0).Item("Na_me"))
For Each OneRow As DataRow In rstData.Rows
Debug.Print("na_me = " & OneRow("Na_me"))
Next
So, you really don't need (or want) a reader anyway. Just load the results into a nice clean, easy to use data table, and from that you can loop the table, grab rows, or do whatever you want.
I am having the problem that about when i try to update a picture, and i click save the error message said that "could not save, locked by another user. where error i did? Sometimes I could update, but sometimes not, why?
And I realize that I have to open Access file and close it then will work.
The error line is cmd.ExecuteNonQuery().
Dim con = New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source =..\room.accdb")
Dim ms As New MemoryStream
Dim arrimg As Byte()
Me.PictureBox1.Image.Save(ms, Imaging.ImageFormat.Png)
arrimg = ms.GetBuffer()
ms.Read(arrimg, 0, ms.Length)
Dim sql As String = "UPDATE Userss SET profilepicture =#profilepicture WHERE studentid=" & Form1.txtStuID.Text & ";"
Dim cmd As New OleDbCommand
con.open()
cmd = New OleDbCommand(sql, con)
Dim photo As OleDbParameter = New OleDbParameter("#profilepicture", SqlDbType.Image)
photo.Value = arrimg
cmd.Parameters.Add(photo)
cmd.ExecuteNonQuery()
MessageBox.Show("Profile picture saved.")
con.close()
The 'locked by another user' is a vague message by MS Access since it can be due to a couple of different reasons. It's not to be confused by a specific reason (such as always meaning a table lock). It can be that or it can be the *.ldb file itself or it can be form/table design or even permissions related. However, in your scenario, you are getting it since you have opened the db on MS Access as you mentioned. Opening the db / tables, usually put a lock on the tables.
When you open a record or the form (or table structure) is not designed optimally or someone opens the mdb/accdb who doesn't have both read and write permissions to the folder and file. This error has to do with the *.ldb file associated with the *.mdb/accdb file which is actually what is 'locking' and causing the error.
Some options can be considered, like;
using a NO LOCK in your update statement, but that might not be the best one.
make sure all your connections are well disposed after use.
use using blocks for your objects that implement IDisposable.
you can also read a bit about DEADLOCKS, it might help avoid locks
This should work:
Dim arrimg As Byte()
Using ms As New MemoryStream
Me.PictureBox1.Image.Save(ms, Imaging.ImageFormat.Png)
arrimg = ms.GetBuffer()
ms.Read(arrimg, 0, ms.Length)
End Using
Using con As New OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source =..\room.accdb")
con.Open()
Using cmd As New OleDbCommand("UPDATE Userss SET profilepicture = #profilepicture WHERE studentid = #studentId;", con)
Dim studentID As New OleDbParameter("#studentId", Form1.txtStuID.Text)
cmd.Parameters.Add(studentID)
Dim photo As New OleDbParameter("#profilepicture", SqlDbType.Image)
photo.Value = arrimg
cmd.Parameters.Add(photo)
cmd.ExecuteNonQuery()
MessageBox.Show("Profile picture saved.")
End Using
con.Close()
End Using
From the code i can see you mix presentation and data access logic, you should probably limit each of your feature to DAL methods so it's easier to find where your DB connection stay open.
With Using like this you can easily avoid to manually dispose the objects and you can be sure the connection will be closed even with exceptions.
Always use parameters and check for disposable object (like MemoryStream).
I'm trying to load configuration settings into a set of DataTables and then disconnect from the database. I'm sure I am doing something wrong as the DataTables are empty afterwards. Here is the code:
From the top of the class:
'Set up Configuration DataTables
Dim dtDataAlerts As New DataTable
Running the Routine to get the data:
Public Sub ReadDataAlerts()
'Read the configuration for the Data Alerts from the RDB
dtDataAlerts = GetRecordSet("SELECT DataAlertGroups.DataAlertGroup_UID, DataAlertGroups.EmailGroup_UID, DataAlertGroups.EmailTemplate_UID, EmailTemplates.EmailTemplate_CustomSubject, EmailTemplates.EmailTemplate_CustomMessage FROM (DataAlertGroups INNER JOIN EmailGroups ON DataAlertGroups.EmailGroup_UID=EmailGroups.EmailGroup_UID) INNER JOIN EmailTemplates ON DataAlertGroups.EmailTemplate_UID=EmailTemplates.EmailTemplate_UID")
End Sub
The routine to get the DataTable
Function GetRecordSet(SQLString As String) As DataTable
'function used to run a query and return a disconnected DataTable
Try
'Create Dataset, Open Connection
Dim dsPWC As New DataSet()
Dim OleDbDataAdapter1 As System.Data.OleDb.OleDbDataAdapter = New System.Data.OleDb.OleDbDataAdapter(SQLString, sqlConn)
sqlConn.Open()
'Fill the Dataset with the PlantWatchConfiguration Table
OleDbDataAdapter1.Fill(dsPWC, "CollectorAlertGroups")
'Create Table from Dataset and iterate data
Dim DT As New DataTable
Dim DTClone As New DataTable
DT = dsPWC.Tables(0)
DTClone = DT.Clone
'Close Connection
sqlConn.Close()
Return DTClone
Catch ex As Exception
WriteToLog(ex.Message, "GetRecordSet")
End Try
End Function
I know the SQL is correct as I have already run it against the RDB and it produces results. I have a ton of logging to file in my code, so I am sure the database is connecting properly. (And other direct queries pull back data just fine)
But I am doing something wrong on the GetRecordSet function. I'm thinking that I am not properly cloning and disconnecting?
Anyway... I'm sure this is simple since I am not a coding expert :)
Thanks.
The error is exactly the Clone method. It clones the datatable structure, not the data.
DataTable.Clone: Clones the structure of the DataTable, including all DataTable schemas
and constraints.
If you want the data you need to use the Copy method.
DataTable.Copy: Copies both the structure and data for this DataTable.
However, as I have said in my comment, you don't need to waste the memory of your PC in this way.
ADO.NET is based on the disconnected model. The datatables present in the Dataset filled by the adapter are already disconnected from the database and you could return directly the table at index zero without any useless copy/clone.
I have included database in my project(at root).
The connection string
Data Source=|DataDirectory|\TSM_DB.sdf;Password=xxx;Persist Security Info=True;Max Database Size=512
TSM_DB.sdf properties:
Build Action = Content
Copy to Output Directory = Copy if newer
Dataset properties:
Build Action = None
Copy to Output Directory = Do Not Copy
My problem:
When I try to insert data into the database it gets inserted to the database present in Debug folder and not in the database which is included in the project...
And that’s why (obviously) my select statement does not find any record in the database (according to my connection string)...
I think the query (code) is perfectly fine, but some sort of settings need be done.
How do I solve this issue?
EDIT :
Example Select Code (working : when connection string path is Absolute)
Try
Dim cnt_temp
Dim SQLquery As String
Dim myConString As String = My.Settings.TSM_DBConnectionString
con.ConnectionString = myConString
SQLquery = "SELECT * FROM tbl_outward"
Dim DA As SqlCeDataAdapter, Ds As New DataSet, Dtb As New System.Data.DataTable
DA = New SqlCeDataAdapter(SQLquery, con)
DA.Fill(Ds)
Dtb = Ds.Tables(0)
cnt_temp = Dtb.Rows.Count
MsgBox(cnt_temp)
con.Close()
Catch ex As Exception
MsgBox("Error..!", MsgBoxStyle.Exclamation)
End Try
When I try to insert data into the database it gets inserted to the database present in Debug folder and not in the database which is included in the project...
Which is exactly what you told it to do, and is what you want. The database in your project folder is part of the source code. When you test or debug your code, the data changed is part of your test or temporary debug output, not your source code.
When you test your code, would you want the test overwriting your source code? I hope not, that would destroy your source; and when you deploy your project you don't usually deploy your source code. The same is true of your data; the data in your project is part of your application and is not the end-user data. When you install your application your source data gets installed to DataDirectory, which is part of your application and is not user data; the user may not even be able to write to it.
When you uninstall or update your application, DataDirectory gets uninstalled or updated. You don't want to do that to your user's data; would you like it if every time you updated Microsoft Word it deleted every Word file on your drive? That's what would happen if Word stored user data in its equivalent of DataDirectory.
DataDirectory is only for your app's private use. If a user needs this data you should copy it to a user-writable place that won't get deleted, like Environment.SpecialFolder.ApplicationData.
Further explanations at this answer.
I'm trying to connect to to a foxpro table (.dbf) from a test vb.net form.
I recieve an OleDbException with the message "Cannot open file c:\emp\emptbl.dbf"
Have tried with both of the following connection strings:
Provider=VFPOLEDB.1;Data Source=C:\emp\emptbl.dbf
from the MSDN article here
Provider=vfpoledb;Data Source=C:\emp\emptbl.dbf;Collating Sequence=machine;
from connectionstrings.com
The latter seems to be the type to use when connecting to a single table, but the same exception is thrown regadless of which is used.
I can open and perform the same query okay in visual foxpro 6.0.
Here's my code:
Dim tbl As DataTable = New DataTable()
Using con = New OleDbConnection(conString)
cmd = New OleDbCommand() With {.Connection = con, .CommandType = CommandType.Text}
Dim sSQL As String = "SELECT * FROM(EMPTBL)"
cmd.CommandText = sSQL
Dim adp As OleDbDataAdapter = New OleDbDataAdapter(cmd)
Dim ds As DataSet = New DataSet()
con.Open()
adp.Fill(ds)
con.Close()
If (ds.Tables.Count > 0) Then
tbl = ds.Tables(0)
End If
End Using
Return tbl
The OleDB provider should only connect to the PATH where the tables are... not the actual file name. Once you connect to the PATH, you can query from ANY .Dbf file that is located in it
Provider=VFPOLEDB.1;Data Source=C:\emp
select * from emptbl where ...
You can also look at other connection string settings at
ConnectionStrings.com
UPDATE per comment.
It appears you are getting closer. with your attempt without the () parens. In VFP, within parens, it interprets that as "look for a variable called EMPTBL", and from its value is the name of the table to query from. Not something you would need to apply via OleDB connection.
Now, cant open the file is another. Is it POSSIBLE that another application has the table open and the file is in exclusive use? and thus can not be opened by the .net app too? Even for grins, if you open VFP, and just do a simple create table in the C:\Emp folder and put a single record in it, then you know no other program will be using it as it is a new file. Quit out of VFP and try to query THAT table. There should be no locks, no other program is expecting it, so it should never be opened by anything else and you should be good to go.