I am being forced to port a SQL load script to VBA in Access 2007 where I read flatfiles and then insert into SQL Server (using ODBC and parameterized query strings). Can someone post a full example of how to use either DAO querydef or ADO so that my inserts are executed in a single transaction on the SQL Server? I not need linked tables, file is read and all transforms are done in VBA prior to insert and done using stored procs and triggers in SQL Server after the load. But I do need to be able to rollback my multiple-inserts if there is an ODBC error.
None of the other stackoverflow posts I've found make much sense to me; all I know is that "ODBCDirect workspaces" are not supported in Access 2007. Does using ADO and BeginTrans make the most sense for me?
Related
My application consists of a Master Excel workbook WB, and any number of Client Excel Workbooks. All contain reports driven by SELECT QUERYs driven by Excel Data Connections to SQL Server via SQLOLEDB and now MSOLEDBSQL. Those QUERYs in SQL Server include data from the Master WB which is accessed by SQL Server via Microsoft.ACE.OLEDB.12.
The Master WB also creates Stored Procedures in SQL Server using DROP PROCEDURE and CREATE PROCEDURE, whose SQL is configured by data in Excel. Reports in Client WBs are driven by Data Connections that EXEC those SPs. This way I can "hide" file structures of data being picked up from Excel, and also provide a single point of control of the SP SQL. I expect this is a not-unusual structure.
This all worked quite well until sometime last year, 2019. Research now shows that Excel broke this in Version 1907. We're well beyond that now, I'm on version 2004. Now all the SELECTs still work, and EXECs still work as long as they invoke SELECT in an SP. But DROP and CREATE from the Master WB no longer function, and calling an EXEC from Excel to invoke an SP to do the DROP or CREATE also fails.
Others have encountered related issues:
A discussion at Microsoft Tech Community indicates this was broken in Excel Version 1906 and fixed in 1908 - but I haven't found it to fix my configuration. (For reference, found an enumeration of Excel Versions; I'm on Version 2004 of Office 365 ProPlus/Microsoft 365 Apps for Enterprise) (Other config info: Win10 Pro, SQL Server Express 2019, Visual Studio Community 2019, everything x64);
Another Microsoft Tech Community discussion on Disabling warnings on Native SQL QUERYs seems to be helpful, but is not a solution by itself. Also discussed on StackOverflow;
A discussion at Power BI Community indicates that following a Native SQL QUERY with "SELECT 1 FROM someExistingTable" solves the problem. I've found that to be helpful too but also not a solution by itself.
I've found that I can make DROP PROCEDURE work if I have
Disabled Native SQL QUERY Warnings as above;
Followed the DROP statement with a SELECT 1... statement as above;
And the Connection builder in Excel now forces me to connect to a Table in Excel, even if the SQL in the Connection does not return data (e.g. DROP or CREATE). Even if I don't select a Table when defining the Connection, I am required to assign the connection to a table in Excel when exiting the builder. I hate this, but it does make DROPs work. I've been re-using a single Data Connection for DROP and CREATE and to execute some EXECs, updating the SQL commandtext by VBA to the appropriate SQL as needed.
However... Even with all these little workarounds, CREATE PROCEDURE still doesn't work. So I'm looking for help on how to make a Native SQL QUERY to CREATE PROCEDURE work in the current Excel Version.
If there's broader advice and outlook on command-oriented (i.e., not returning data) Native SQL QUERYs in Excel Data Connections, that's also of interest! Thanks.
I'm working on a project where I need to automatically run an insert statement to insert a result set - problem is that I need it to go from a SQL Server over to a DB2 server. I can't create a file or script and then import it or run it on the other side. I need to insert or update the DB2 side from the SQL Server side.
Is this possible? I need this to run all by itself as part of a stored procedure in SQL Server.
You're looking for the linked server feature.
Typically linked servers are configured to enable the Database Engine to execute a Transact-SQL statement that includes tables in another instance of SQL Server, or another database product such as Oracle. Many types OLE DB data sources can be configured as linked servers, including Microsoft Access and Excel. Linked servers offer the following advantages:
The ability to access data from outside of SQL Server.
The ability to issue distributed queries, updates, commands, and transactions on heterogeneous data sources across the enterprise.
The ability to address diverse data sources similarly.
(I believe most of the major RDBMSs have a similar feature)
For the most part, this essentially allows you to treat tables or sources in the other database as if they were part of the SQL Server instance - an INSERT statement should just work "normally".
As mentioned you can use a linked server on the SQL Server side to perform operations between two servers. I haven't done much with running DML on DB2 from SQL Server, but from my experience SSIS performs far better than linked servers for transactions pulling data from DB2 to SQL Server using an OLE DB connection. You can read more about OLE DB connections in SSIS here and you'll want to reference the DB2 documentation for the specific DB2 type (Mainframe, LUW, etc.) that's used for details on setting up the connection there. If you setup the SSIS catalog you can run packages using SQL Server stored procedures, which you can either use directly or execute from an existing user stored procedures.
I have an MS Access application with data in a separate access mdb. We need to move the data to MS SQL. Previously when I did this is worked very well - dramatic speed improvements. In this new upgrade however, we are seeing some problems with translating of the SQL from Access to SQL.
We have the solution separated into an APP mdb and a DATA MDB. We use Linked-tables to join the two. After migrating the data to SQL server, we created an ODBC link, then re-pointed the linked-tables to the SQL data source over ODBC. We would expect the SQL command generated by Access, to be simply transferred to SQL server, for SQL server to operate on same using its normal efficiency and power.
When I put a trace on SQL Profiler, instead of seeing for example a simple "Delete * from table", we see a series of delete statements, one for each record in the table ...
We see the same thing for updates - where we would expect for example "insert into table1 (select a,b,c from table2)...) to be sent as an SQL string, to be executed on the server, we instead see a series of insert statements, one per row being inserted, being sent to the server.
It seems that Access is trying to work out the logic for everything but select statements client side and not letting MS SQL server take care of things as one would expect.
Anyone experienced this behaviour before and can offer a suggestion to resolve?
thanks.
I need to transfer certain information out of our SQL Server database into an MS Access database. I've already got the access table structure setup. I'm looking for a pure sql solution; something I could run straight from ssms and not have to code anything in c# or vb.
I know this is possible if I were to setup an odbc datasource first. I'm wondering if this is possible to do without the odbc datasource?
If you want a 'pure' SQL solution, my proposal would be to connect from your SQL server to your Access database making use of OPENDATASOURCE.
You can then write your INSERT instructions using T-SQL. It will look like:
INSERT INTO OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0','Data Source=myDatabaseName.mdb')...[myTableName] (insert instructions here)
The complexity of your INSERTs will depend on the differences between SQL and ACCESS databases. If tables and fields have the same names, it will be very easy. If models are different, you might have to build specific queries in order to 'shape' your data, before being able to insert it into your MS-Access tables and fields. But even if it gets complex, it can be treated through 'pure SQL'.
Consider setting up your Access db as a linked server in SQL Server. I found instructions and posted them in an answer to another SO question. I haven't tried them myself, so don't know what challenges you may encounter.
But if you can link the Access db, I think you may then be able to execute an insert statement from within SQL Server to add your selected SQL Server data to the Access table.
Here's a nice solution for ur question
http://www.codeproject.com/Articles/13128/Exporting-Data-from-SQL-to-Access-in-Mdb-File
I have some Access tables with many number of fields. I have migrated each access table to 6 or 7 sql server tables. I am using sql server 2008. Now I want to use Access as the front end so that I can enter the data in access but it will be stored in sql server. I know that I have to make a ODBC connection. But I am not sure of how to create a access form to use it as a front-end. I am sorry if it's a basic question...
You will probably want to start with an empty Access database (since the table structures and any existing forms and reports will not match what you created in SQL server).
First step is to establish an ODBC connection to your SQL Server database. Then you will "link" the tables in SQL Server to your Access database.
Now, you have an Access database with all the tables that you linked from SQL Server. Those tables still "live" in SQL Server and when you edit them in Access the data will be stored in SQL Server.
You can then build Access forms and reports using these tables just as if the tables were native to Access.
The most versatile way is to use ODBC links to your SQL Server tables and views. That approach allows you the flexibility to link to other ODBC data sources, tables in other Jet/ACE database files, create Jet/ACE tables locally in your database, link to Excel spreadsheets, and so forth. You can incorporate a broad range of data sources.
If you choose ADP, you will be limited to OLE DB connection to a single SQL Server instance. And you will be essentially locked in to SQL Server. You would not be able to switch the application to a different client-server database without a major re-development effort.
Regarding deployment overhead with ODBC, although you may find it convenient to use a DSN during development, you should convert your ODBC links to DSN-less connections before deployment. That way your user's won't each require the DSN. See Doug Steele's page: Using DSN-Less Connections
Well you can create an ODBC connection. You can also create an ADODB connection as well. If your objective is to update or modify a SQL database, both connections will do the trick.
Now, I guess you have to get familiar with the corresponding objects. These should be tables, queries, commands, etc .., that will allow you, for example, to build recordsets out of SQL queries ... Once you are clear with that, you can, for example, assign a recordset to a form through the Set myForm.recordset = myRecordset.open ... method.