Conversion error in Visual Studio not showing data types - sql

I'm running into an issue when trying to view a report I set up in visual studio. The report is throwing a conversion error (which I'm familiar with), but it's not showing any information about that conversion error. see screen shot below (I guess I can't embed the image, so please see link). This is running a stored procedure I set up in SSMS, and in that stored procedure everything works just fine. There are three queries and a stupidly simple export with 4 fields. All of the individual queries work just fine.
The conversion error appears to be involving a parameter I set up in the report. This parameter labeled 'performance' is varchar(30) and only interacts with other varchar(30) data types. I literally only compare it to a single field that is of the exact same data type, and do not use the parameter for any other purpose. The reason I say I believe this is the issue is because when previewing the report in visual studio, I can enter a performance name with single quotes around it, and the error doesn't appear (although this isn't helpful because it passes along the single quotes and therefor messes up the match).
I run visual studio and SSMS through a hosted platform, so every angle of this is interacting with a remote server and remote applications. Nothing is stored in house.
Any help here would be much appreciated! I've already discussed this with the company hosting our applications, but without knowing whether or not this issue is server-side or on my end, they're unwilling to assist.

Related

SSRS Deployed Report Not Executing WHERE clause

I have an SSRS report that works perfectly in Visual Studio 2017.
But when I deploy it, the deployed report comes back with all the data, ignoring the filters in the WHERE clause. I know it's this because when I remove the WHERE clause from my Visual Studio report, the data matches the deployed report.
This report pings off a shared data source; the dataset is not a shared.
Even a simple WHERE tbl.flag = 'Y' does not seem to do anything to the deployed report.
Why is SSRS not recognizing the entire SQL?
Not really an expert in SSRS, I just make them based off some YT tutorials and deploy them to the link that was given to me, so any advice or links for research are appreciated.
Check the server setting in the report project properties in Visual Studio.
If they look OK then delete the server copy of the report and redeploy.
If the report does not reappear then that proves that the report is either
a. not being deployed (you should see an error in the visual studio output window), or
b. it's being deployed to where you think it should be.
From the web portal you can search for a report by name and it will search all folders on the server so if it did deploy OK, you could find it that way.
I have discovered the issues was some inline comments I had in the SQL. I had some comments above the WHERE clause using dashes, --, explaining the filter. Once I removed it, the report executed correctly.
I was also able to change the comment style to the /* <my comment> */ and it executed correctly. It seems that other style of comments with dashes made the server think everything afterwards was a comment, and therefore not executed.

Weird SQL Server stored procedure behaviour - different results between asp.net and Management Studio

We have a stored procedure that’s used to populate a SSRS Report. It’s a bit of a monster – loads of conditional logic (in case statements), casts (sometimes embedded in other casts) from varchar to datetime, and 3 fields that rely on calls to a function that contains some date functions . The report contains financial information for a list of contracts for one organisation.
I need to create an asp.net page that shows a subset of the data for one organisation/contract so I cloned the sproc and added a contract parameter. However I noticed the figures for the 3 fields that rely on the function are different on the web page from when the stored procedure is run directly on the database or through the report.
To troubleshoot I created a page (quick and dirty using SqlDataSource and DataGrid) that shows the results of the original stored procedure showing all contracts. The query runs fine through Enterprise Manager but the web page crashes with the YSOD and the message
The conversion of a nvarchar data type to a datetime data type resulted in an out-of-range value.
I even tried hardcoding the SQL from the stored procedure into the web page but still get the same results
On my dev machine the original stored procedure runs and my new stored procedure does return consistent results regardless of whether viewed through the web page or Management Studio. The regional settings etc are same on the dev server and live server. The only different thing I can think of is that the live web server and db server are on separate machines.
Has anyone come across anything like this before??
Thanks
Thanks to lad2025 for the fix and Vanlightly for the reason:
I added the following statement to the start of the stored procedure and it now returns consistent results regardless of where it's called from:
SET DATEFORMAT ymd;
The SQL login being used by the web application has its default language set to British English whereas the other accounts are set to English

Access is not showing the records I have entered through vb.net form

I am new in vb.net programming. Am facing a problem in database handling. Am using oledb to deal with database, which is MS Access in my project. I am dealing with queries at the time. Now the problem is that my queries are working well on vb form but are not affecting the actual database. For example, when am adding a record, it displays 'record added successfully', the message I have used for my conformation, but the actual database is not displaying the record I just entered and even got the above conformation message as well. I have checked query in sql editor too, its doing well. I have checked locals in vb debug mode, all are containing correct values.
Am not getting what's the reason behind that. Why it is displaying the success message but not modifying the actual database. Same is the case when am firing delete query, till now. I have not tried Update query yet.
Technology - Visual Basic.net with MS Access
Am using Access 2007 and Visual Studio 2013
Please Help by your suggestions
Do the controls on your form have the correct control source, i.e. the database table/query from and to which it should be reading and writing to?
Basically the problem was the gap between my understanding and .Net's working.
Here is the solution.
You can include database in two ways:
1.Either importing it directly to your project from the place, for example using drag and drop, or some other such method.
2.Or, by including it via using wizard.
But, the difference lies in connection string you use in your project, if you give absolute path of database, then you will directly see the alterations in database you have done using your application, even in testing and debugging mode via IDE.
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\xyz.accdb"
But if you are using connection string provide by wizard, for example,
connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\xyz.accdb"
what the IDE will be doing is whenever you will be running project for debugging or testing, every time, it will copy the actual database, with its contents as well, in /bin/Debug folder. So, the changes you are performing will only be visible to that copy, not the actual file. So, if you want to verify with the database, like in our case, check the copy of database, which will be present in /bin/Debug folder. You will see the changes there. But, every time you run project for debugging, it will replace that copy with original one.
So, actually I was checking the original database file, not that copy, since the changes were only made to that copy. So that is why I was facing the above problem, not due to any programming fault.

Specified query not executable here - pentaho reporting

So I've designed a report in Pentaho Report Designer 3.9 and previewed it and ran it on my machine and everything works fine.
I have an input paramater that is a dropdown list and gets its values from a query called Vertical-List.
Now the drop down works on my machine. However, when I publish the report to the Online interface and try to access it, I get a message that says "The Specified query 'Vertical-List' is not executable here". I don't know what that means and what to do. It worked this morning and suddenly it stopped working.
Please help a brother out.
here is the query that generates the drop down
SELECT
`verticals`.`vertical_id`,
`verticals`.`vertical_name`
FROM
`verticals`
Double check your datasource and query, especially the parameters. If you have parameters, remember that a parameter is read in the Pentaho Report Designer as ${parameter_name}.
Also double check that you have defined the datasource in your BI Server.

Reporting Services: Exported to Excel results are different than the ones viewed on IE

I'm having this problem:
The SQL Server holds a said value, let's say 990.30, the Reporting Services Report show a different value (948.33) when viewed online, in the brower and a third value (912.22) when the report is exported to Excel.
There are no formulas on Excel, just plain values.
Also, there's no formula on the layout of the report.
The code shows only a simple select that, when run on the SQL Server Management Studio, returns me the original value (990.30).
How on earth shall I start to troubleshoot this ?
I've never heard of this kind of problem before. I would recommend submitting a ticket to Microsoft and provide them with screen shots of the errors, the RDL file, a sample output of the stored procedure, etc.
To troubleshoot this on your own, I would recommend creating a new report that just has a simple table that returns all the details from your stored procedure or query to validate the values are consisten across all interfaces. From there, just start adding on complexity until you get the report to look like it is today.