MS-Access - Setting parameters for pass-through query - sql-server

I have a pass-through query (for SQL Server) in Access which works with explicit values. For a non-pass-though query, I just use the visual editor to create parameters for the affected columns.
Is it possible to do the equivalent with a pass-through query or must I assemble the query with VBA (as mentioned in another post)?
TIA,
Paolo

Unfortunately, you cannot. It would be once possible with ODBCDirect workspace but that was removed since Access 2010. Therefore, for pass-through queries, you would have to concatenate SQL.
A possible alternative is to use ADO which allow you to create parameters and thus construct a command and execute it. Note that your project doesn't have to be limited to only DAO; you can use both DAO and ADO, leveraging what works best for your requirements.

Related

How to introduce a parameter to SQL server using MS Access as a front-end UI?

I am using MS Access as a front-end and using an ODBC SQL Server Driver for data.
How is that I can parameterize my query using a field from an MS Access form?
Here is my current working query (however, I need DALLAS to be a parameter I can pass from a MS Access form):
Select LPID,Name_Long, MR_Markets from baf_center
Where Guild_Markets = 'DALLAS';
Should this be handled in VBA instead?
Any help would be appreciated.
If I understand you correctly, you have field in a form and you want to use that in the where clause of a query. If so, you could reference the form field like so in the criteria of the query designer:
[Forms]![Your Form]![Your Form Field]
Let me know if I'm off-base about what you're trying to do.
Are you using linked tables to a SQL Server database. If so, it is an actual ODBC query.
You might be able to reference [Forms]![Your Form]![Your Form Field] in the criteria window entry under the Guild_Markets column. However, you have to do something with the results?
You can also execute the query via VBA.
I guess the main question is what are you trying to do?

Performance issue: t-sql vs clr

I am just wondering which will be faster t-sql function/procedure or clr version of one? A procedure works with database data and use cursors (t-sql version).
When should I use clr and when I should use t-sql to create procedures and functions?
Simple rule-of-thumb:
data manipulation (SELECT, UPDATE etc.) are best left to T-SQL (but without cursors!)
while anything that has to do with processing (string/regex matching, date arithmetic, calling external web services etc.) is a good match for SQL-CLR

Compatible DDL (CREATE TABLE) across different SQL databases?

I'm working on a desktop application that must support (currently) MS Access and SQL Server back ends. The application is under constant development and changes are frequently being made to the database, mostly the addition of tables and views to support new features (but also some DROPs and ALTER TABLEs to add new columns).
I have a system that compiles the DDL into the executable, checks the database to see if the executable has any new DDL that has to be executed, and executes it. This works fine for a single database.
My immediate problem is that SQL Server and Access support wildly different names for data types so a CREATE TABLE statement that executes against Access will not execute against SQL Server (or worse, will execute but create a table with different datatypes).
Is there a method that can be used to create DDL (especially CREATE TABLE commands) that can be executed through ADO against both of these databases without having to craft separate DDL for each provider?
Since you are already using ADO, you should look into Microsoft ADOX
This allows you to manipulate structures in a data source using an ADO object model that is independent of the underlying data source type. i.e. without resorting to explicit DDL
Support for ADOX is not guaranteed by any given ADO Provider, and the level of ADOX support may vary even when it is available. But for MS Access and MS SQL Server I think you will find all the capability you require (and quite possibly more!)
This can be done using DBX in Delphi.
The following is links to sample code showing how this can be done.
http://cc.embarcadero.com/item/26210
I had the same problem.
I resolved it applying a C preproccessor to the SQL before executing it.
The preprocessor includes macros in order to handle the different dbs.
Stefano
Did you check
http://db.apache.org/ddlutils/
or
http://publib.boulder.ibm.com/infocenter/wtelecom/v6r1/index.jsp?topic=%2Fcom.ibm.twss.plan.doc%2Fdb_scripts.html

Can I call an SQL Server's user defined function from Microsoft Access

I'm trying to upsize my Access application to an Access FE and a SQL Server database BE.
One of the problem I have is that queries with "filtering parameters" are executed client-side and require all rows to be sent from the server to the client.
example:
SELECT * FROM MyTable WHERE MyId = Forms!MyForm!MyControl.Value;
This query will require all the rows from MyTable to be sent from the SQL Server to Access that will eventually execute the WHERE clause.
I've read about SQL Server's User Defined Function and it looks like it could work for me if only I could call them from Access the same way I can do in a SQL Server Query.
Can I do this?
Is MyID indexed? If so, then Access shouldn't be dragging the entire table across from the server.
I'm not sure where you're getting the criteria from, though, as that's not the SQL that a form filter is going to send. Or even a saved QueryDef with a hardwired reference to a control on a form.
Try dropping .Value (it's redundant as it's the default property).
Also, if it's a saved QueryDef, try defining the control reference as a parameter, i.e., PARAMETERS Forms!MyForm!MyControl Long;.
Basically, nothing that you report is standard Access behavior with ODBC linked tables to SQL Server. If it were, Access would be hell to upsize, and it's not at all.
Should be possible with a "pass-through" query.
I agree, a pass-through query will do it, but that will leave a persistent query object in your application window.
Using ADO recordset and connection objects will allow you to return filtered results into your recordset, but you'll need to write TSQL statements, which differ from Access SQL.

SQL Stored Proc : How to pass a collection of files to a stored proc?

My program has code that saves attachments, I want these attachments to be transferred to the database, and I am going to use a stored procedure to accomplish this.
I need to know what is the #param type to accept an array of binary files?
finally once I have this array, how to I insert this data into a SQL table?
I guess I am looking at using a byte[] for 1 file, but how do I pass from C# or .net a collection of byte arrays to the SP, and what should the param type be to accept this array of byte[]
Updated
Need a solution that will work in 2005 and 2008.
Update
I've decided to scrap the idea of having 1 large SP to process everything. Instead I am going to have smaller SPs, then handle the transaction in .net.
Do you think this would be a better solution, to handle the transaction in .net data objects?
If you were needing only to pass an array of values, I would suggest to format them as XML and pass them as the SQL xml datatype. You can perform select from XML with SQL just as easily as from a table.
It may also technically work if you pass binary data in XML, but I'm not sure it will be a good solution. Anyway, it is an option.
For SQL Server 2008, you can use the table-valued parameter feature.
This allows you to define a parameter of a table type, and then supply values to that parameter as a DataTable from your C# code.
See these blog posts and articles for more information:
SQL Server 2008: Table-valued parameters
Using Table-Valued Parameters in SQL Server 2008
This is a new feature of SQL Server 2008, so you won't have this in SQL Server 2000 or 2005.
UPDATE: if you need to support SQL Server 2005 as well, check out Erland Sommarskog's excellent article Arrays and Lists in SQL Server 2005. It offers a few ideas on how to accomplish this in 2005.
Marc
See Arrays and Lists in SQL 2005. This article aggregates pretty much every technique there is out there and discusses the advantages and problems with each approach.
I decided to create just one SP, and call it multiple times, one for each file I need uploaded, and keep the transaction managed in C# code.

Resources