Do somebody know how can i write in SQL language in Visual FoxPro a query with parameters? It doesn't work in the same way like it does in Access and I am a little bit lost here.
Thank you in advance!
Unfortunately your question is too broad to provide a simple answer.
The syntax for one query will vary from the syntax to perform a different query.
And Yes, the SQL Query syntax is likely slightly different than M$ Access.
However you can always do a Google search for: vfp sql query syntax to find specific syntax equivalents.
Note: The "WITH" parameters will be in a simple WHERE clause similar to most other SQL Query languages,
Such as WHERE Field1 = "ABC" AND Field2 = 235
but it will be using the VFP language syntax.
Also you might want to spend some time looking at the free, on-line VFP tutorial videos at: free on-line VFP tutorial videos
Specifically the one labeled: FoxPro and the SQL Language
You can visit w3schools.com to see SQL basics. It doesn't work like access, that is true, because access, which is a so called SQL database engine, has its own understanding of the SQL. VFP OTOH is closer to ANSI SQL (IOW closer to SQL Server).
You haven't specified the language you are using, but saying access, I would assume you are trying with VBA. Here is a sample in VBA (excel) using parameters:
Sub Macro1()
Dim oRecordset1 As ADODB.Recordset
Dim oConnection As ADODB.Connection
Dim oCommand As ADODB.Command
Dim oParameter1 As ADODB.Parameter
Dim oParameter2 As ADODB.Parameter
Set oConnection = New ADODB.Connection
Set oCommand = New ADODB.Command
oConnection.ConnectionString = "Provider=VFPOLEDB;Data Source=C:\Program Files (x86)\Microsoft Visual FoxPro 9\Samples\Northwind"
oConnection.Open
oCommand.ActiveConnection = oConnection
oCommand.CommandText = "select * from Orders where OrderDate >= ? and OrderDate < ?"
Set oParameter1 = oCommand.CreateParameter("start")
oParameter1.Type = adDate
oParameter1.Value = CDate("1996-08-01")
oCommand.Parameters.Append oParameter1
Set oParameter2 = oCommand.CreateParameter("end")
oParameter2.Type = adDate
oParameter2.Value = CDate("1996-10-01")
oCommand.Parameters.Append oParameter2
Set oRecordset = oCommand.Execute()
Sheet1.Range("A1").CopyFromRecordset (oRecordset)
End Sub
Note: Parameters are positional, not named.
It depends on what kind of query you're using, either using the built-in SQL engine that queries native FoxPro tables or if it's a query using an external data source.
First for the case of a native query, it's really simple. Since it's a native FoxPro instruction, you can access to every single feature out there, including variables, where you can simply put your user supplied data without worries:
LOCAL data &&This could come from user input
data = "hello world"
SELECT * FROM SomeTable WHERE Column = data &&Filtered parametrized query
The other option is to submit a SQL query for an external server to process, where the query is sent as a text string. In this case, special markers for parameters can be used, matching FoxPro variables, and in turn that would result in a parametrized query sent to the server:
LOCAL data
data = "hello world"
LOCAL hConn = SQLSTRINGCONNECT(connectionString)
SQLEXEC(hConn, "SELECT * FROM SomeTable WHERE Column = ?data", "SomeTable") &&The "?data" parametrizes the query, sending the value separate from the query itself
SQLDISCONNECT(hConn)
Related
I have a list of Users Names in ComboBox and Some TextBoxes. When ComboBox text changes (i.e I select some username from ComboBox), The TextBoxes are filled with user details from the database.
I have code to achieve this in SQL Database. But these queries are not working with MsAccess database.
MysqlConn = New MySqlConnection
Mysql.ConnectionString = "server=localhost;user=root;password=root;database=database"
Dim READER As MySqlDataReader
Try
MysqlConn.open()
Dim Query As String
Query("select * from database.usernames where name='" & ComboBox1.Text & "'")
Command = New MySqlCommand(Query, MysqlConn)
READER = Command.ExecuteReader
While READER.Read
TextBox1.Text = READER.GetString("name")
End While
End Try
Here is my answer. Please don't get overwhelmed by it. ;)
Broken code
First of all, as I see it, the code you provided cannot work at all, because:
your Query variable is initialized in an invalid (or at least a very exotic) way. You probably want to use something like:
Dim Query As String
Query = "select * from database.usernames where name='" & ComboBox1.Text & "'"
or in a single line:
Dim Query As String = "select * from database.usernames where name='" & ComboBox1.Text & "'"
you try to assign the connection string to the ConnectionString property of a nonexistent Mysql variable. Or the variable exists because it is declared somewhere else, which might be a bug in your code snippet here. But I assume you want to assign the connection string to the MysqlConn.ConnectionString property instead.
you have not declared the MysqlConn and Command variables anywhere. You only just assign to them. (I will simply assume you have declared the variables correctly somewhere else in your code...)
the IDataRecord interface does not provide a GetString(name As String) method overload. So unless you have defined a custom extension method for it, you probably need to use the IDataRecord.GetOrdinal(name As String) method as well, or use the column index instead of the column name.
Anyway, the code you provided uses MySQL. So I assume that MySQL is the "SQL Database" you are using successfully. And that seems to work, as you say? Well... Hmmm... Then I will simply assume your code snippet is completely correct and works perfectly with MySQL... :/
MS Access vs. MySQL
Using MS Access requires other data access classes (probably the ones in namespace System.Data.OleDb) and another connection string. You could take a look at this ADO.NET OleDb example for MS Access in the Microsoft documentation.
You probably even have to update your SQL query, because every database system uses its own SQL dialect. You might want to consult the Office documentation for that. But your query is quite simple, so perhaps all you have to do to make it work with MS Access is:
remove the database name and use only the table name, and
delimit the name identifier (since it is a reserved keyword in MS Access).
I personally delimit all identifiers in my SQL queries, just to avoid unintended conflicts with reserved keywords. So I would personally use something like this:
select * from [usernames] where [name] = '...'
Additional tips
Also, I would like to provide you some additional (unrelated) tips regarding improving your code:
Use Using-statements with variables of an IDisposable type as much as possible. Those types/classes do not implement that interface if there isn't a good reason for it, so I consider it not unimportant to call Dispose when you are done with such disposable objects (or using a Using statement to call Dispose implicitly).
Use SQL parameters (if possible) to avoid SQL injection vulnerabilities. Look at this StackOverflow question and its answer for an example of how to use SQL parameters with MS Access.
Example
You may take a look at the following code snippet. It might not provide a working example out-of-the-box, but you might get some useful/practical ideas from it:
Dim connectionString As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\\Data\\database.mdb;User Id=admin;Password="
Dim query As String = "select * from [usernames] where [name] = #Name"
Using conn As New OleDbConnection(connectionString)
Using command As New OleDbCommand(query)
command.Parameters.Add("#Name", OleDbType.VarChar, 50).Value = ComboBox1.Text
conn.Open()
Using reader As OleDbDataReader = command.ExecuteReader
If reader.Read Then
textbox1.Text = reader.GetString(reader.GetOrdinal("name"))
End If
End Using
End Using
End Using
I am trying to write a Excel VBA macro that runs a query based upon a variable in the spreadsheet. The existing data is half in a large data base (MS Access) on the network.
For some reason when my code runs, nothing is pasted back to my spreadsheet. Can you see why this may be the case:
Sub test()
Dim cnn As New ADODB.Connection
Dim rst As New ADODB.Recordset
Dim ConnectionString As String
Dim StrQuery As String
ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;DataSource=\\network\data07\version6.mdb;"
cnn.Open ConnectionString
cnn.CommandTimeout = 900
StrQuery = "SELECT dbo_vwData_SelectAll.BusinessDate, , dbo_vwData_SelectAll.Flowdate, dbo_vwData_SelectAll.Bucket FROM dbo_vwData_SelectAll WHERE (((dbo_vwData_SelectAll.Line)=""1.1.1.4"") AND ((dbo_vwData_SelectAll.ReferenceID) Like ""rent*"");"
rst.Open StrQuery, cnn
Sheets("Sheet2").Range("A2").CopyFromRecordset rst
End Sub
The above is a test - I will be changing "rent*" for other variables based on strings in the spreadsheet.
Thanks in advance.
The misappropriated LIKE operator is a known issue in the MS Access SQL dialect. When using MSAccess.exe GUI program, LIKE uses the asterisk wildcard, *. However, using MS Access via ODBC as a backend database as you are with Excel, LIKE uses the ANSI wildcard, %. See MS Office Support docs on Access wildcard character reference.
Therefore, consider the following adjustment which includes use of single quotes:
SELECT dbo_vwData_SelectAll.BusinessDate,
dbo_vwData_SelectAll.Flowdate, dbo_vwData_SelectAll.Bucket
FROM dbo_vwData_SelectAll
WHERE (((dbo_vwData_SelectAll.Line)='1.1.1.4')
AND ((dbo_vwData_SelectAll.ReferenceID) LIKE 'rent%');
To be consistent in either frontend or backend interfaces, consider the ALIKE operator:
AND ((dbo_vwData_SelectAll.ReferenceID) ALIKE 'rent%');
I am updating someone elses old code from a VB6 windows application to a VB.Net web application. I understand the old code, but I am not sure how I would translate it to .Net recordsets.
myStoredProcedure = "sp_WritevPayrollCurrent"
myCurrentPast = "'N'"
myStoredProcedure = "sp_ObtainSubClassID"
myClassName = "Payroll Major"
mySubClassName = "New Hire"
Set rs = TgetReadResultsetWithParms(myClassName, mySubClassName, (myStoredProcedure))
Also, I am not sure what will happen with "myStoredProcedure" being declared twice or could that be an error?
The TgetReadResultsetWithParms function is as follows (some Cases redacted to free up space):
Dim en As rdoEnvironment
Dim cn As rdoConnection
Dim rq As rdoQuery
rdoDefaultCursorDriver = rdUseServer
'open a connection to the tstdbexecutive database using DSNless connections
Set en = rdoEnvironments(0)
Set cn = connectionstring stuff here
Select Case myStoredProcedure
'create reusable rdoQuery and Call SQL server stored procedure.
Case "sp_ObtainClassID"
Set rq = cn.CreateQuery("", "{call " & cstDatabaseName & ".dbo.sp_ObtainClassID(?)}")
Case Else
Set rq = cn.CreateQuery("", "{call " & cstDatabaseName & ".dbo." & myStoredProcedure & "(?)}")
End Select
'set the input argument value for the store procedure.
rq(0) = myParm1
'open the Resultset and pass it back to calling procedure
Set TgetReadResultsetWithParm = rq.OpenResultset(rdOpenKeyset, rdConcurReadOnly)
The VB6 code is using Remote Data Objects. I think you will have to read the documentation to understand what the VB6 is doing, and then rewrite in VB.Net using ADO.Net to achieve the same functionality. AFAIK there is no handy cheat-sheet which shows how RDO compares with ADO.Net, unfortunately. There are some for ADO-ADO.Net.
Alternatively you could add a reference to Remote Data Objects in your .Net project - you can use COM objects in .Net - and then use the same code. If there is a large amount of the old code, this could be a pragmatic way to make the task more manageable, although it makes the code harder to understand for other programmers who would probably be used to ADO.Net. It's better to rewrite if you can afford to.
I currently have a SQL 2008 R2 database backend with an Access 2013 accdb front end with ODBC DSN-less connection and linked tables. In SQL I have many parameterized tSQL UDFs created to feed data into reports (currently working well in my Access 2010 adp frontend). The reports are complicated: multiple tSQL UDFs run calculations and then feed into a final UDF that feeds the respective report. I would like to keep the UDFs on the server – rewriting into Access queries would be a poor solution.
My problem is that I have not been able to figure out how to write the VBA correctly to send a pass-through query to call the tSQL UDF and give it a parameter, which would change for each report. I know pass-through queries are read-only, that’s ok. I’ve read that I can call a stored procedure (SP) from VBA, but can I call the UDF rather than having to convert each to a SP or create a SP just to call the UDF so that I could call the SP from VBA. Based on my research, I think I might have to either create a SP to call the UDF or convert the UDF to a SP to get the VBA to work (i.e., return results without error). Is this correct?
I found this discussion: https://social.msdn.microsoft.com/Forums/office/en-US/898933f5-73f9-44e3-adb9-6aa79ebc948f/calling-a-sql-udf-from-access?forum=accessdev , but it has conflicting statements “You can't call a tSql udf from Access.”, and “You can use a passthrough query to call UDF's or stored procedures or anything else written in tsql.” Also, their code is written in ADO instead of DOA so it’s a bit cryptic to me since I’ve only written DAO so far, but the general gist that I got was they converted their UDF to a SP.
I found this article a great read, but again did not get a clear “yes” to my question:
http://technet.microsoft.com/en-us/library/bb188204(v=sql.90).aspx
It may be possible to remove the parameter from the Server side and add it to the Access side similar to this Access 2007 forms with parameterized RecordSource , but wouldn't that cause Access to load the entire dataset before filtering, instead of processing on the Server side – possibly causing performance issues?
I can successfully create a pass-through query in the Access interface if I supply it with a constant parameter, for example “Select * from udf_FinalReport(2023)”, but what I really need is to be able to pass a dynamic parameter. For example, the parameter would be from Forms!Control![txtboxValue]. Can I do this? The following code is what I’m using– it works if I use a table name in the SQL (ex, “SELECT * FROM Table WHERE tblYear = “&intYear ) in line 9 so I feel like I have everything coded right, but when I put my UDF in the SQL like below I get the error #3131 “Syntax error in FROM clause.” (I did verify that I should not use the prefix schema (dbo.) – this gives error 3024 “could not find file”.) Is this user error or just plain telling me I can’t call a UDF this way?
1 Sub AnnualSummary()
2 Dim dbs As DAO.Database
3 Dim qdfPoint As DAO.QueryDef
4 Dim rstPoint As DAO.Recordset
5 Dim intYear As Integer
6 intYear = Reports!Annual_Delineation_Summary!txtYear
7 Set dbs = OpenDatabase("", False, False, "ODBC;DRIVER=sql server;SERVER=******;APP=Microsoft
8 Office 2010;DATABASE=*******;Network=DBMSSOCN")
9 Set qdfPoint = dbs.CreateQueryDef("", "Select * from udf_AnnualReport(" & intYear& ")")
10 GetPointTemp qdfPoint
11 ExitProcedure:
12 On Error Resume Next
13 Set qdfPoint = Nothing
14 Set dbs = Nothing
15 Set rstPoint = Nothing
16 Exit Sub
17 End Sub
18
19 Function GetPointTemp(qdfPoint As QueryDef)
20 Dim rstPoint As Recordset
21 With qdfPoint
22 Debug.Print .Name
23 Debug.Print " " & .SQL
24 Set rstPoint = .OpenRecordset(dbOpenSnapshot)
25 With rstPoint
26 .MoveLast
27 Debug.Print " Number of records = " & _
28 .RecordCount
29 Debug.Print
30 .Close
31 End With
32 End With
33 End Function
I also tried writing the code a little differently, using the following instead of lines 5, 6, and 9. This also works when I use a table name in the select statement, but I get error #3131 when I use a UDF name:
Set qdfPoint = dbs.CreateQueryDef("", "Parameters year int; Select * from Point_Info where
year(Sample_Date) = year")
qdfPoint.Parameters("year").Value = intYear
Both code variations also work if I try use the name of a SQL View in the tSQL SELECT statement.
My consensus is using ADO language instead of DAO to write the pass-through query works well. But, I have found that it is still probably better to execute a stored procedure than to try to call the UDF. Here is the code that ended up working most smoothly for me: (my ADO Connection uses Public variables strUID and strPWD)
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strPoint As String
strPoint = Forms!FRM_Vegetation_Strata!Point_ID
Set cn = New ADODB.Connection
cn.Open "Provider = sqloledb;Data Source=imperialis.inhs.illinois.edu;" & _
"Initial Catalog=WetlandsDB_SQL;User Id=" & strUID & ";Password=" & strPWD
Set rs = New ADODB.Recordset
With rs
Set .ActiveConnection = cn
.Source = "sp_Report_VegWorksheet '" & strPoint & "'"
.LockType = adLockOptimistic
.CursorType = adOpenKeyset
.CursorLocation = adUseClient
.Open
End With
Set Me.Recordset = rs
On a side note I found that to get set the .Recordset to fill a subform put this code in the "Open" event of the subform.
Then to clean up your connection:
Private Sub Form_Unload(Cancel As Integer) 'use "unload", not "close"
'Close the ADO connection we opened
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Set cn = Me.Recordset.ActiveConnection
cn.Close
Set cn = Nothing
Set rs = Nothing
Set Me.Recordset = Nothing
End Sub
This approach does not work for populating a report. "Set Me.Recordset" only works for forms. I believe I will have to call a stored procedure then populate a temp table to use as the report recordset.
EDIT: I have found that I can call a SQL UDF or SP from VBA in Access using DOA. This is particularly helpful when one wants to pull the data from a complicated SQL function/procedure and put it into an Access-side temp table. See Juan Soto's blog https://accessexperts.com/blog/2012/01/10/create-temp-tables-in-access-from-sql-server-tables/#comment-218563 This code puts the info into a temp table, which is what I wanted to populate my reports. I used his code example and the following to call the sub:
To execute as SP: CreateLocalSQLTable "testTBL","exec dbo.sp_Report_WetDet_point '1617-1-1A'",False
To call a UDF: CreateLocalSQLTable "testTBL","Select * from dbo.QryReport_Main('1617-2-2A')",False
I don't know if it's the most efficient method of passing a variable parameter through a pass-through query into a function and returning the results to Access, as I am still relatively new to Access, but I came across this earlier when I was attempting a similar problem.
I managed it by creating a couple of pass-through queries that executed functions in SQL server and returned a result. I then made a small VBA script that re-wrote the pass-through queries with the new variable every time I wanted to change it, and executed them.
I got the result back out using OpenRecordset, and stored it as a string to use in the rest of my code.
I want to find the text in textbox in my database. I wrote the code below. It finds numbers well, but when I want to find strings it gives a runtime error: invalid column name for example aaa, but aaa exists in column1 in my table.
What do you think about the problem?
cmd = New SqlCommand("select * from tbl where column1=" + TextBox1.Text)
cmd.CommandType = CommandType.Text
cmd.Connection = cnn
dad.SelectCommand = cmd
cmd.ExecuteNonQuery()
dad.Fill(ds)
dgv.DataSource = ds.Tables(0)
That's because the sql statement you send is not delimiting the TextBox1.Text value so you end up with this sql:
select * from tbl where column1 = aaa
and SQL Server treats aaa as a column name.
Regardless of that, you should be using a SqlParameter to avoid sql injection attacks:
cmd = New SqlCommand("select * from tbl where column1=#value")
cmd.CommandType = CommandType.Text
cmd.Paramaters.AddWithValue("#value", TextBox1.Text)
VB is not my primary language, so the syntax might be a little off, but you should be able to make it work.
Adritt is right, you must enclose the text to find within single quotes and, provided that very text doesn't contains single quotes, all is well - Apart for the risk of SQL attacks.
That being said, you are using an outdated, obsolete way of coding your app against the database.
You should definitively have a deep look at LINQ technology where:
You have no connection to open or close: its automatic
You don't have to cope with quotes, crlf and commas
You do not risk SQL attacks: queries are parameterised by the LINQ engine
You will benefit from intellisense againts the database objects: tables, views, columns
You get a straightforward result to use as the datasource!
For INSERT and UPDATE statements transactions are automatically enabled.
Example:
using ctx as new dataContext1
dim result = from r in ctx.tbl
where r.column1 = textBox1.text
dgv.datasource = result.tolist
end using
Intellisense:
When you type "ctx.", you are presented with the list of available tables!
When you type "r." you are presented with the list of column the table (or vieww) contains!
LINQ is not difficult to learn and you'll find tons of examples to help you, here and there on the web.
Last but not least, you can use the LINQ SQL-like syntax to query XML data, CSV files, Excel spreadsheets and even the controls in your form, or the HTML DOM document in ASP.NET!