How do I make a stored procedure in MS Access?
Access 2010 has both stored procedures, and also has table triggers. And, both features are available even when you not using a server (so, in 100% file based mode).
If you using SQL Server with Access, then of course the stored procedures are built using SQL Server and not Access.
For Access 2010, you open up the table (non-design view), and then choose the table tab. You see options there to create store procedures and table triggers.
For example:
Note that the stored procedure language is its own flavor just like Oracle or SQL Server (T-SQL). Here is example code to update an inventory of fruits as a result of an update in the fruit order table
Keep in mind these are true engine-level table triggers. In fact if you open up that table with VB6, VB.NET, FoxPro or even modify the table on a computer WITHOUT Access having been installed, the procedural code and the trigger at the table level will execute. So, this is a new feature of the data engine jet (now called ACE) for Access 2010. As noted, this is procedural code that runs, not just a single statement.
If you mean the type of procedure you find in SQL Server, prior to 2010, you can't. If you want a query that accepts a parameter, you can use the query design window:
PARAMETERS SomeParam Text(10);
SELECT Field FROM Table
WHERE OtherField=SomeParam
You can also say:
CREATE PROCEDURE ProcedureName
(Parameter1 datatype, Parameter2 datatype) AS
SQLStatement
From: http://msdn.microsoft.com/en-us/library/aa139977(office.10).aspx#acadvsql_procs
Note that the procedure contains only one statement.
Related
Does MS Access support stored procedures on .accdb or .mdb databases? Or are stored procedures only supported when the backend is SQL Server or something else that supports an Access DB engine (Jet / ACE/ MSDE)?
Information is mixed and not quite complete from what I have found on MS Access and Stored Procedures from various sources. For example this Access help file initially looks like Access supports stored procedures.
https://support.microsoft.com/en-us/office/create-procedure-statement-91c700d1-8076-4040-896a-a0b7cf9d9888?ns=msaccess&version=90&ui=en-us&rs=en-us&ad=us
When I try to run the following query, it errors saying I have incorrect syntax for CREATE TABLE statement. The table is in an .accdb file on my local laptop.
CREATE PROCEDURE GetReport (pFileId Integer)
AS
SELECT * FROM FileInfoTable WHERE FileId = pFileId
Some Access DDL features are only available when the statement is executed with ADO. Your statement will succeed if you execute it from CurrentProject.Connection.Execute as this Immediate window example demonstrates:
strSql = "CREATE PROCEDURE GetReport (pFileId Integer)" & vbCrLf & _
"AS" & vbCrLf & _
"SELECT * FROM FileInfoTable WHERE FileId = pFileId"
CurrentProject.Connection.Execute strSql
However notice that the SQL text in the saved query object does not exactly match the text in the CREATE PROCEDURE statement. But I think it's functionally equivalent.
Debug.Print CurrentDb.QueryDefs("GetReport").SQL
PARAMETERS pFileId Long;
SELECT *
FROM FileInfoTable
WHERE FileId = pFileId;
Well, yes, access does have what is called table triggers, and access also has what we call stored procedures (procedural code that can run at the table level - or in fact you can even call such stored procedures from VBA, or macros).
However, just like MySQL, SQL server, Oracle and more? They ALL HAVE their OWN type of code system for these stored procedures. Access is no different.
This feature and ability was introduced in Access 2010. However, this feature, this ability has ZERO to do with the SQL supported CREATE procedure command.
That command was introduced to give "some" compatibility with SQL Server syntax - but it is quite lame, and limited. WHEN you use CREATE PROCEDURE in Access SQL, it ONLY creates a select command. As such, the select command is JUST THAT - ONLY a select command and is NOT procedural code.
However, as noted, you can write stored procedures in Access, and they run by the data engine, and they run at engine level. To write these routines, you have to use the macro language. This language is NOT VBA, and not T-SQL (SQL Server code), but Access has its OWN syntax and code.
These so called table routines are thus created when working on a table in design mode.
While such code is limited, it is REAL procedural code, does not use SQL syntax in most cases, and such routines can be called from table events.
And these so called "data macros" are not created with SQL data create commands, you are limited to using the built in macro editor for this purpose.
Keep in mind that while Access has this stored procedure code ability, they are not transaction based. But, they can be of GREAT use, since they even function when using OLEDB or ODBC sources to Access.
So, if you write such code, and then say open Access with FoxPro, or even c# in .net? And then you update a row? The procedural table code and triggers WILL run.
You can see these options here:
So, I could for example maintain the total cost of an invoice for each change, or edit, or adding of rows to a sub form.
The macro language editor looks like say this:
So you can loop over data, you have if/then else etc.
It is a very limited language - but they are in fact true real stored procedure code that runs at the table level, and they run 100% independent of VBA or any other code.
And these table stored procedures run:
when edit data in a form - even forms without code
when you issue SQL update or modify statements
when you modify data via VBA + recordset code
if an external ODBC or OLEDB source such as .net c# or whatever modifies data
All--
(Ducking to avoid the flames....) I would like to use Google Data Studio to create simple reports from MySQL data. For each of several reports, I have written a corresponding MySQL stored procedure that has a single parameter, pEndDate (a CHAR(10) string in the format yyyy-MM-dd). It seems simple enough to use MySQL tables and views as data sources for Google Data Studio, but I haven't seen any documentation or blog posts re: stored procedures. Any and all comments are welcome.
Thanks,
Matthew P. Seltzer
P.S. I am running MySQL 5.6 on Windows 10 Pro.
MPS
You may try making the stored procedure a function then you can call that in a SELECT, you may need to experiment a bet with getting the function to trigger before the datasource selecting from the views and tables, but it's worth a shot.
I want to run the following procedure first:
exec ep_upd_server_abc
Then execute the following statement:
SELECT * FROM dbo.Server_Warehouse
WHERE Enabled = 'f' and disabledweekly = 'f'
Can I write the following procedure in SSRS Query Builder so that I can execute two statements?
CREATE PROCEDURE ShowDBJob
As
Begin
exec ep_upd_server_abc;
SELECT * FROM dbo.Server_Warehouse
WHERE Enabled = 'f' and disabledweekly = 'f'
End
Is there a work around for this?
I tried running this in SSRS Query Builder and it's giving me an error. Would appreciate any thoughts and suggestions...Thanks!!
Why not just do this exact procedure for
CREATE PROCEDURE ShowDBJob
As
Begin
exec ep_upd_server_abc;
SELECT * FROM dbo.Server_Warehouse
WHERE Enabled = 'f' and disabledweekly = 'f'
End
in SQL Management Studio and call that? Don't do any type of real time event driven coding or procs in SSRS IMHO. Slippery slope where you are trying to use the equivalent of a screwdriver for a hammer and vice versa. SQL Managment studio is meant for designing proc's and accessing the SQL Server Database for it's object creation directly. SSRS is meant to return data connections, results for a dataset, evaluating presentation of datasets on one or many objects to display and not much more except features/syntax around those things. Even accessing temp tables '#(something)' and parameters declared on the fly 'declare #thing int (inside statement of dataset)' make it get mad. Stick with predefined programable objects or procedures and functions already created. Do not try to create them on the fly.
Plus think about this. Everytime you are calling your dataset you cannot create that object each time as it already exists. Then you are going to have to either alter it or drop it and recreate it first. SSMS already does this part in options for you and stores them in the database. SSRS is an add on to SQL Server but is not full featured for creating objects. Especially on the fly.
No, You cannot write "Create Procedure" or any other DDL statements from Query Designer in RS. This is by design.
We host multiple SQL Server 2008 databases provided by another group. Every so often, they provide a backup of a new version of one of the databases, and we run through a routine of deleting the old one, restoring the new one, and then going into the newly restored database and adding an existing SQL login as a user in that database and assigning it a standard role that exists in all of these databases.
The routine is the same, except that each database has a different name and different logical and OS names for its data and log files. My inclination was to set up an auxiliary database with a table defining the set of names associated with each database, and then create a stored procedure accepting the name of the database to be replaced and the name of the backup file as parameters. The SP would look up the associated logical and OS file names and then do the work.
This would require building the commands as strings and then exec'ing them, which is fine. However, the stored procedure, after restoring a database, would then have to USE it before it would be able to add the SQL login to the database as a user and assign it to the database role. A stored procedure can't do this.
What alternative is there for creating an automated procedure with the pieces filled in dynamically and that can operate cross-database like this?
I came up with my own solution.
Create a job to do the work, specifying that the job should be run out of the master database, and defining one Transact-SQL step for it that contains the code to be executed.
In a utility database created just for the purpose of hosting objects to be used by the job, create a table meant to contain at most one row, whose data will be the parameters for the job.
In that database, create a stored procedure that can be called with the parameters that should be stored for use by the job (including the name of the database to be replaced). The SP should validate the parameters, report any errors, and, if successful, write them to the parameter table and start the job using msdb..sp_start_job.
In the job, for any statement where the job needs to reference the database to be replaced, build the statement as a string and EXECUTE it.
For any statement that needs to be run in the database that's been re-created, doubly-quote the statement to use as an argument for the instance of sp_executesql IN THAT DATABASE, and use EXECUTE to run the whole thing:
SET #statement = #dbName + '..sp_executesql ''[statement to execute in database #dbName]''';
EXEC (#statement);
Configure the job to write output to a log file.
I am in need of a stored procedure for sales transaction. In a single SP I need to store CustomerID in one table and list of products purchased (multiple rows) in another table.
Can any one give me an best example?
Thanks in advance.
Table-Valued Parameters is a new feature introduced in SQL SERVER 2008. In earlier versions of SQL SERVER it is not possible to pass a table variable in stored procedure as a parameter, but now in SQL SERVER 2008 we can use Table-Valued Parameter to send multiple rows of data to a stored procedure or a function without creating a temporary table or passing so many parameters.
You can read about it here
for more information about using it with ado
check this great article
SQL Server 2008 Table-Valued Parameters and C# Custom Iterators: A Match Made In Heaven!
well in the stored procedure you can use any many insert commands as you want in any table you want, as your question is not clear enough that i write the exact stored procedure you want, I'm writing an example.
use [databasename]
go
create procedure [dbo].[my_stored_procedure](#customerid int) as
begin
insert into [customerstable](customerid) values (#customerid)
insert into [someothertable](somefieldname1, somefieldname2) values(somefield1value, somefield2value)
insert into [someothertable2](somefieldname1, somefieldname2) values(somefield1value, somefield2value)
end