I'm not that experienced in sql server and even less so in using SSRS. I'm working with 2008 R2 edition.
Question: Is it possible to use a sql table that has expressions in a report, so that the report will evaluate the expressions before it is run? I just tried and the expressions don't get evaluated and show up as string. The expressions are stored as string in the sql table. Not sure if there is another way to store the expressions?
Thanks in advance for your help.
Cheers,
In SSRS, it sends the query to database engine and execute. Once the data is retrieved from database, the data is fixed. Then report will process the data and render it. And the query is executed only one time. You can't make the query re-process the expression within the cell again.
Related
We have a migration task, which require to migrate ~30GB data from SQL server to SAS grid. We already have close to 50 reports using SSIS/SSRS and those need to move entirely to SAS grid. I am more familiar with SAS and haven't worked on SSIS/SSRS stuff.
How do I go about moving the process to SAS?
I know I can use Passthrough in SAS to call the SSIS/SSRS stuff from Proc SQL, but since they want everything needs to be coded in SAS, I am wondering if there is an easy way.
Is there a tool that can convert the SQL code and writes Proc sql code in SAS?
Thanks!
Park
You should be able to view the queries behind the SSIS jobs (run the report, then view the details behind it). Once you have the queries, copy/paste the SQL code into a SAS SQL passthrough statement. The table returned should give the same results as the report. It's then up to you to format the output as desired.
I need to get each statement of given SQL Server stored procedure.
To achieve this, I generate execution plan XML and look for "StmtSimple" nodes in query.
This approach is quite slow for large procedures.
Is there any way that I can get every single statement of the procedure without generating XML execution plan?
When you have the text of a stored procedure, you can perform a full parse on it using the TransactSql ScriptDom. If you just want to get each statement, it's possible to do that using this method.
However, I'm not convinced that it would actually perform much better than using the method you are using now. It's just another option to try.
Edit -> The ScriptDom is part of the SQL Server 2012 Feature Pack, and is contained in the 'SqlDom.msi' install.
I have had an odd error I cannot explain. Basically, I am running a query to my SQL database using excel and am having non-existent data pop up when it comes to a very particular order in my database.
Here is a simple query surrounding this order:
select * from OR200100 where OR200100.OR20001='0000793605'
Here is the output in EXCEL
And here is the same output in SQL
what is happening here? How could the same query generate 2 different results?
Run SQL Server Profiler against the database if you can, then compare the output to the sql query that you are running in ssms.
OK, so it's SQL Server then, that's important because different SQL products can have very different idiosyncrasies and controls.
The next things to check are these:
Is OR200100 a Table or a View? If it's a view then post it's code.
Are you using the same Login/account from both Excel and SSMS?
Are you sure that you are connecting to the same Server and Database? SSMS tells you what you are connected to, but client apps like Excel do not and it is very common for this type of problem to be caused by the app connecting to a Dev or QA version of the database. See here for some of the different ways that this can happen:
So I had a very similar problem, my query was grouping by week numbers. What I found was that one of the queries had set datefirst 5 set whilst the other didn't. I guess the key thing here is make sure, if you are using any SET operations in your ssms queries, these are identical to those in the Excel query string.
What is a dynamic SQL query, and when would I want to use one? I'm using SQL Server 2005.
Here's a few articles:
Introduction to Dynamic SQL
Dynamic SQL Beginner's Guide
From Introduction to Dynamic SQL:
Dynamic SQL is a term used to mean SQL code that is generated programatically (in part or fully) by your program before it is executed. As a result it is a very flexible and powerful tool. You can use dynamic SQL to accomplish tasks such as adding where clauses to a search based on what fields are filled out on a form or to create tables with varying names.
Dynamic SQL is SQL generated by the calling program. This can be through an ORM tool, or ad-hoc by concatenating strings. Non-dynamic SQL would be something like a stored procedure, where the SQL to be executed is predefined. Not all DBA's will let you run dynamic SQL against their database due to security concerns.
A dynamic SQL query is one that is built as the program is running as opposed to a query that is already (hard-) coded at compile time.
The program in question might be running either on the client or application server (debatable if you'd still call it 'dynamic') or within the database server.
I have written SQL statements (stored in a text document) that load data into a SQL Server database. These statements need to be repeated daily. Some of the statements use the NewId() function to populate a keyed field in the database, and this works fine.
While I'm in the process of writing an application to replicate these statements, I want to use Access queries and macros instead of copying and pasting queries into SQL Server, thus saving me time on a daily basis. All is working fine but I can't find any function that will replace the SQL Server NewId() function. Does one exist or is there a work around?
I'm using SQL Server 2005 and Access 2007.
On top of matt's answer, you could simply use a pass-through query and just use your existing, working queries from MS Access.
A solution would be to insert the stguidgen() function in your code, as you can find it here: http://trigeminal.fmsinc.com/code/guids.bas https://web.archive.org/web/20190129105748/http://trigeminal.fmsinc.com/code/guids.bas
The only workaround I can think of would be to define the column in your access database of type "Replication ID" and make it an autonumber field. That will automatically generate a unique GUID for each row and you won't need to use newid() at all. In SQL server, you would just make the default value for the column "newid()".
Again, there seems to be confusion here.
If I'm understanding correctly:
You have an Access front end.
You have a SQL Server 2005 back end.
What you need is the ability to generate the GUID in the SQL Server table. So, answers taht suggest adding an AutoNumber field of type ReplicationID in Access aren't going to help, as the table isn't a Jet table, but a SQL Server table.
The SQL can certainly be executed as a passthrough query, which will hand off everything to the SQL Server for processing, but I wonder why there isn't a default value for this field in SQL Server? Can SQL Server 2005 tables not have NewId() as the default value? Or is there some other method for having a field populate with a new GUID? I seem to recall something about using GUIDs and marking them "not for replication" (I don't have access to a SQL Server right at the moment to look this up).
Seems to me it's better to let the database engine do this kind of thing, rather than executing a function in your SQL to do it, but perhaps someone can enlighten me on why I'm wrong on that.