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.
Related
I am building a report in SSRS using Visual Studio 2010 Design view. I am using a stored procedure as my data set. When I run out the stored procedure in SQL Server, it runs fine. When I run it out in preview, I am missing some columns.
In the stored procedure, I join a table that lives on a linked-server through a synonym. These seem to be the missing columns in the preview.
Is there a known issue where linked-server data will not get returned in SSRS even if it compiles in SQL Server?
This is probably due to permissions if you have the linked server set to execute as the context of the current user - it will use the credentials of the Data Source in SSRS.
Is your data source configured to use a specific user? Try running the sproc as that user?
-- Edit based on Comments --
It appears the issue is probably with the linked server authentication. There are a few ways round this;
Set up Kerberos pass-through authentication so you can tick 'Be made using the login's current security context' in the linked server properties
https://blogs.msdn.microsoft.com/farukcelik/2008/01/02/how-to-set-up-a-kerberos-authentication-scenario-with-sql-server-linked-servers/
https://www.databasejournal.com/features/mssql/article.php/3696506/Setting-Up-Delegation-for-Linked-Servers.htm
Use a SQL (not Windows) account on the remote server by ticking 'Be made using this security context' and entering the sql accounts details
Use a scheduled job of some kind to transfer the data the sproc returns over to one server so that linked server connection is not required
Change the report to query both data servers separately (as two different data sources and data sets), then join the results within the report (this is a bit fiddley and not really recommended)
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?
I'm wanting to take data from a SQL Server table and populate a Oracle table. Right now, my solution is to dump the data into a Excel table, write a macro to create a sql file that I can load into Oracle. The problem with this is I want to automate this process and I'm not sure I can automate this.
Is there an easy way to automate populating a Oracle table with data from a SQL Server table?
Thanks in advance
I suppose it depends on your definition of "easy".
The most robust approach would be to either use heterogeneous connectivity in Oracle to create a database link to the SQL Server database and then pull the data from SQL Server or to create a linked server in SQL Server that connects to Oracle and then push the data from SQL Server to Oracle.
Yes. Take a look at MS SQL's SSIS which stands for SQL Server Integration Services. SSIS allows all sorts of advanced capabilities, including automated with Sql Server Jobs, for moving data between disparate data sources. In your case, connecting to Oracle can be achieved a variety of ways.
There are three ways to automate this:
1) You can do as Paul suggested and created an SSIS package that will do this and it can be scheduled via SQL Agent,
2) If you don't want to deal with SSIS, you can download the free SQL# (SQLsharp) CLR Library from http://www.SQLsharp.com/ and use the DB_BulkCopy Stored Procedure to do this in a T-SQL Stored Proc which can also be scheduled via SQL Agent. [note: I am the author of SQL#]
3) You can also set up a Linked Server from SQL Server to Oracle, but this has the draw-back of being a potential security hole. Of course, you could use an Oracle Login that only has write-access to that single table (or something similar to that).
There are lots and lots of ways to do it. Which you choose depends on your requirements.
Using Excel is fine if it's a one time thing.
If it's a once-in-a-while thing, then you could write a simple .NET app that uses a single DataSet and multiple DataAdapters to do the data dump. C# code example here.
if it's a regular thing, then you could put the above in a Schtasks task, or you could use SSIS. I think SSIS is an extra-cost option.
if the requirement is for "online access", then a linked database is probably appropriate.
I'm trying to replicate a rather large database from SQLServer 2000 to SQLServer 2008, located on two different servers. I found an article about attempting this and have been trying to follow its direction. Here is the article.
Mixed Mode Bi-Directional Transactional Replication between SQL 2000 and SQL 2008
Here is the part I'm stuck on:
"So, to create a publication, you will
need to NOT use the publication wizard
that you get in SQL 2008. Instead, use
a generated publication script and for
each sp_addarticle line that you have
in it, make sure that the #ins_cmd,
#upd_cmd & #del_cmd parameters point
to the appropriate stored procedures
and run it on the SQL Server 2000
server. Once this is done, go ahead
and create a subscription to SQL
Server 2008’s database normally."
I was able to get the stored procedures in place for all of the tables but need some direction on creating a generated publication script. Does anyone have some direction or a good example of a generated publication script?
On the final step of the publication wizard you will have the two options:
1. Create the publication
2. Generate a script file with steps to create the publication
The article referenced here is suggesting that you do not let the wizard create the publication but instead only choose to generate the script file. At that point you can edit the script file as instructed in the article.
You can run through the SQL Publication Wizard in 2008 and have it output to a script and then use that as a base model to modify with the appropriate arguments for the sp parameters listed in the question.
I'm just doing an upgrade of SQL 2000 to SQL 2008 R2 and I'm finding the publication wizard works just fine without any need to modify the scripts generated.
The article suggests creating some stored procs because it does not work bi-directionally out of the box. However, when it works brilliantly both directions, and very quickly too, just using the wizard. This is using SQL 2008 R2 which may be the reason, it may have improved since the original SQL 2008.
I have managed to get SQL Server 2005 Express up and running on my computer Ok in order to do some testing before trying this in the "Real World".
I have a fairly large MS Access 2007 Database application I need to migrate to SQL Server
retaining the "Front End" as the user interface. (The app' is already a "split" database
with a Front and Back end....)
I have done some initial testing on using SSMA to migrate my Access database To SQL
Server Express.
Clearly I don't understand some things and I thought I'd see if anyone has
any ideas.
Conceptually I thought that what needed to happen was that the Back End of the
database that resides on the server needed to be migrated to SQL server
and then the Front End re linked to the (now linked to SQL) tables in the Back End.
When I do this using SSMA I end up with renamed tables in the Back End
Access file that look something like "SSMA$myTableNameHere$local". I also
get the original table names underneath showing as ODBC linked tables.
So far so good.
BUT.... When I go to re-establish the linked tables from the FRONT END (The
user interface) all I can see is the "SSMA$myTableNameHere$local" names NOT
the original table names.(Now linked via ODBC)
I can link to the "SSMA,,,," tables but it would mean changing the names of
every table in every query and on every form and in all code on the Front
End! Not something I really want to do.
SO....
I thought I'd try to migrate the FRONT END and see what happens.
What I ended up with is a situation where, basically it works (there are
some serious errors and issues that I haven't even looked at yet... like
missing data etc.!!!!) and I still get the "SSMA$myTableNameHere$local"
tables and the ODBC linked tables with the original names.
I'm trying to understand...... Does this mean that we would do the
migration on the Front End and then just copy the same file to each user's
computer?
Another subject I'm a little confused about is that I can't link via ODBC
to SQL Server Express on the local machine (ie my computer) so I can't test
migrating the Back End and then linking to the tables via the Front End as I
have in the past in more of a client/server situation.
Assuming that SSMA replaces the tables in your back end with links to the SQL Server, all you need to do is delete the original table links in your front end and import the newly-created table links from the back end. You can then discard the back end, since it's not used for anything at all any longer.
I did transfer all my tables one by one to SQL Server 2005 fro Access DB back-end using ODBC.Instruction:
Open Access DB(back-end)
Right-click on table, you need to transfer
Scroll down drop-down box and select ODBC Databases
Select Data Source dialog box opened, Click "New" button
Create new data source dialog box opened
Scroll to the bottom and select SQL Server, Click Next
Give name to your Data Source, Click Next, Click Finish
Create New Data Source Dialog opens
Give some discription OR leave empty, Type Name of your SQL Server (you named it, when install SQL Server on your machine)
Click Next, Click Next
Check "change default database to check box
Select DB where you want your data transfer to
Click Next, Click Finish
NOTE: You need to create new DB (empty) on SQL Server, before doing all this
Now: Right-click any table, select Export, select from drop-down list ODBC, from Data Sources window select your Data Source, You created, Click OK
Use SQL Server with SQL Management Studio Express.
All dates must have a input mask; all text and Memo must have Allow Zero Length =Yes
After all disconnect all links from Access back-end, and establish links from SQL.RENAME all newly linked tables to old names. Use Fron-end user interfase, until do some new.
Forgive my lack of knowledge of Acronym Soup, but I assume SSMA is the SQL Server 2005 "import data wizard" or the wizard in Access to send the data to SQL Server. It appears that you sent the data to SQL Server from Access - something you don't want to do. You want to use the DTS in SQL Server (now called SSIS or something?) to import the data into SQL Server. Then you'll have your tables in SQL Server. Then, simply create your DSN entry for the SQL Server and re-link your tables. All should be well.
Overall, the general rule is to import Access tables using SQL Server instead of using Access to send the data to SQL Server.
I'd bite the bullet and rename the tables on the SQLServer side back to the friendly names that you had in the original database. You'll probably have less problems. Especially if you have any embedded code the MS Access side.
As far as how you will deploy the MS Access side now, it should be pretty much create the ODBC link on the user's workstation, and copy the MS Access file to their desktop (although you might want to make an MDE (or the 2007 equivalent) to prevent them from accidentally breaking it).
Frankly, now that you have migrated, you need to look at the design of your tables. It is my experience that the wizards for Access migration do a poor job of selecting the correct datatype. For instance if you had a memo field, you might easily get away with a varchar field instead but the last wizard I used (an earlier version) always converted them to text fields. Now would also be the time consider some fixes such as making date fileds datetime instead of character based if you have had that mistake in the past.
I would never consider using a wizard again to do data migration myself having experienced how very badly they can do it.
You will alos find that just converting the data to SQL Server is often not eough to really get any performance benefit. YOu will need to test all the queries and consider if you can convert them to stored procs instead if they are slow. Eliminating the translation from Jet SQL to T-sql can being performance improvements. Plus there are many features of t-sql that can imporve performance that do not have Access equivalents. Access is not big on performance tuning, but to get the benefit of performance tuning with a SQL Server backend, you need to have SQL Server specific queries written. INdexing needs to be considered if the Access tables were not indexed properly.
Using SSMA is different when you use odbc. If you have an application using fully access (back end and front end). You can manipulate objects easily bounding forms, using DAO, etc.. without problem, then when u need to migrate database to sql server u can use directly odbc (by linking yourself tables to sql server), ssma, ... the main problem how to preserve bounded forms, queries, code in the client-side.
If U use directly odbc you must relink by yourself all objects and change code but if u use ssma, you have to do nothing, you will continue to work as u did before. The problem with SSMA is how to deploy the front end to the clients if you developed client side in other place using another sql server?