my reports (pdf and excel) sometimes are empty - sql

i have a procedure executed in form to generate data as excel or pdf ,anyway my problem is that sometimes my reports comes with no data and in another time it shows the data .
any suggestions please!!

If you used same parameters every time, then tables' contents is changing between two runs of that procedure. How? Someone updated something or deleted rows or broke foreign key constraints. Because, I don't see a reason why would e.g.
select * from emp
where deptno = 10
produce result "now" and 5 minutes later cause no data to be displayed.
If you think that this is not the case, provide some more info.

If you are running the report/excel from a parameter form then there is a chance that there is not data in your database related to those parameters and that's why the excel and pdf are empty.
and if that's not the case then briefly tell your running method of the reports.
regards: hassan

Related

Microsoft Access Table Shows Up Blank, But Query Correctly Pulls Data From Table

I am having an issue with my Microsoft Access database. One of my tables looks completely blank, but it has 11632 records listed in the bottom. Take a look at this screenshot. Though the table shows up blank, when I run the query it pulls the correct data from this table, so I know the data is there, it is just not appearing for some reason. I have tried on Access 2013 and 2016 on a different computer, and both have the same effect. I have also tried compacting and repairing, and also exporting the table but the file it exports to also appears blank, aside from the field names. Any ideas on what I could try?
Thanks!
Turn your import into a 2 step process (or more...). Write it raw into a scratch pad table. Then fire an append query, that has the appropriate criteria to result in only valid records going into the final table.
This isn't unusual at all given that some outside data sources may not have the controls to prevent bad records. Sometimes one must "wash" the data with several different query criteria/steps in order to filter out the bad guys.

MS Access Error updating memo field with long text

Searching this problem returns quite a few search hits, but many off-track answers, so I'm posting a concise description here, and answer below.
The problem afflicts Microsoft Access 2010, and some versions before. Access 2013 renames Memo type to Long Text. I don't know if it has the same problem.
The root problem is associated with running an UPDATE query on a table with a memo field, in certain particular circumstances. This might be an UPDATE query composed in the visual query window, or some VBA running SQL via DAO or ADO or similar. Or it could arise while updating via a form.
(The current post is concerned with this occurrence just within an Access database, though elsewhere you will find discussion of similar-sounding issues when Access is connected to an external database server.)
Instead of generating an immediate and obvious error alert, Access (or perhaps Jet) places the value #Error (which is not just the string "#Error"!) into the Memo field. This might easily go unnoticed until some later time, resulting in visible errors such as:
-- You use Compact and Repair. That seems to complete, but Access quietly adds a MSysCompactError table with a couple of rows. One error -1611 complains that Access was stopped and couldn't complete the operation. A second, more-specific-seeming error complains that it can't find field "Description". That appears to be an internal error that has no relevance.
-- You try to copy the table to another database. Access gives an error complaining that another user is using the table or has updated the table, and won't complete the operation.
-- Other operations on the rows that, unnoticed by you, happen to contain the #Error values fail.
Regardless, the root problem is whatever causes the #Error values to get placed into the Memo fields in the first place.
Many posters have noted that it occurs if the UPDATE attempts to put strings longer than about 2000 characters into the Memo field. That's a surprise, as Memo fields should be able to hold 1 gig characters or more depending on version, even if it only allows 65k through the UI.
So why does the error occur when Updating using >2000 characters?
The key factor that provokes this error is the Memo field having an index. Apparently, although the Memo type field can hold a bazillion characters, the index can't deal with more than about 2000.
Knowing that this is the precipitating factor, probably a number of workarounds come to mind. First, you can obviously just disable the index. This solution is easy to verify in a dummy database: Create two tables containing Memo fields, one with an index and the other without. Run update queries that put >2000 characters into each Memo and note the results.
But perhaps you think you need the index? Your use case might be satisfied if you create a second field that will contain an initial substring of the main Memo (shorter than 2000 characters), and index that instead. This could be used for sorting purposes for example. In most cases, where a memo contains narrative information, it's unlikely that the memo data values differ only after 2000 characters. Or perhaps you can devise a hash function and make a separate column of that.
What if you have a database that already contains these #Error values? Some advice floating around on the web, especially in relation to downstream problems like failure of Compact and Repair, suggests that your database is corrupt and should be abandoned. I'm not so sure. If you can delete the #Error-afflicted rows, then delete the index, and then recreate the deleted rows, you may be back in business. Compact and Repair should run properly at that point, giving some confidence that you fixed the offending part. (Make backups along the way, obviously.)
Workaround solution
Create two macros (Macro1 Macro2)
Macro 1
Get all the necessary information from the open form which includ this long text and close it.
Macro 2
Insert all needed actions (starting with the update query that you get error)
Create a form (Form_on_error) with only a button that run Macro2
Finally add at the end of macro 1
On Error
Go to :Macro Name
Macro Name: On_Error_2590
RunMacro Macro2
Submacro On_error_2590
OpenForm (Form_on_error)
End Submacro
.......and it works !!!
So, only when the update query get error, the user must click the button on the form : Form_on_error

SSRS - Fields working in Data Set, but won't appear in report

I have a data set that gets its values from a stored procedure, and I'm positive that the stored proc is working correctly since I'm getting results in SQL Server. However, when I call the fields in an expression (for example, =Fields!CustomerName.Value) and preview, it just displays a blank spot in its place. If I simply typed some text in that spot, the text does appear when I run it.
The DataSet IS working, and it's refreshed to show all of the fields. They just don't display anything in the report, despite definitely returning values when I check in SQL Server. Does anybody have any suggestions as to what steps I could take to fix this?
Thanks.
Try referencing your dataset explicitly, by changing this:
=Fields!CustomerName.Value
To this:
=Fields!CustomerName.Value,"MyDatasetName"

Access Query uses Form Inputs as Parameters - Runs manually, not through Form

I have a query that accepts input from a form. The query works as expected when I run it, manually typing in the form input values. However, when I run the query from the form, the query returns blank - no error, just blank.
I don't understand what's causing it - at it's most basic, the user is simply entering a Start and Stop date. I'm entering the data exactly the same, and made sure my form text box is formatted as a date.
Furthermore, when I run the form, I am not prompted for any values, so I know it's reading them accurately. This system works for several similar queries, but not this one.
What I've tried
Changing the format of the text box to specify Short Date (which is how I type it)
Visually confirming the values are making it from the form to the hidden staging area the query references - these values match what I manually enter into the prompts
The query I'm runnning references another query; running the other one by itself only yields one set of "date" prompts, not two. So I created a seperate date input box for each to read off of, but to no avail
Question: Does Access try and format (or not format) parameter input boxes differently than it would handle form references?
Additional detail - when I run the query manually, it prompts me for the dates twice - I don't know why or it's pertinent, but I thought I'd mention it.
use instead Temporary variable in your Query for the specified dates. After you select the dates from the Form, make sure that the values are assigned to the temporary variables and that you requery the record source of the form
I was able to get this working by tweaking my query in the designer - specifically by splitting up my expression into multiple pieces and writing the criteria in segments.
I'm not sure why this did the trick, but it at least got me where I needed to go.
Good luck to anyone else experiencing this!

Dynamic SSRS report

I had a problem in creating the Dynamic report in SSRS. My problem is:
In a table I have stored SQL scripts with the column SQLScripts. If you execute these SQL scripts you get different number of columns for each script.
My problem is, I have one report with buttons of these scripts, for example test1, test2...like that. If you press test1 button this should take the test one SQL script and should display the report with appropiate columns in that sqlscripts.
I can't create individual reports for each test report, they are plenty. Are there any options for me to solve this problem...
The only way I've been able to get this to work sofar is:
Each report has 2 datasets.
ReportData
DataHeaders
The "DataHeaders" need to have the proper name of the datafields in "ReportData". Be careful since SSRS replaces blanks and special characters with "_"
Now, create a table (or matrix) and drag the DataHeaders as the Columns of your report. (This should be a grouped column). If you run it at this point, you'll see all your columns without any data. Now comes the magic:
Create another report that takes a "DataField" parameter. Create another table or matrix within this report and set it's dataset property to be "ReportData". In the DATA cell for the table, set it to the expression =Fields(Parameters!DataField.Value).Value
Now go back to your first report. Right click and insert a subreport. Right click on the subreport and select "Subreport Properties". Under general, select the second report you created to be used as the subreport. Under parameters, select the DataField parameter and set its value to something like =Fields!DataField.Value
In my case I did some formatting in this expression to fix the above mentioned issue with spaces and special characters, since my stored procedure was initially used in ASP.NET and this was just a proof of concept.
Also in my experience the performance isn't great. In fact it was kinda slow, though I haven't had a chance to switch it to use a shared dataset, which I suspect would help a bit. Please let me know if you find a better solution.
I have not found a way to do this completely dynamically. Here is a similar question with some possible solutions:
How do i represent an unknown number of columns in SSRS?
You basically need to create a 'master dataset' from the other Datasets that are based on your multitude of SQL scripts first.The master dataset should contain the data to be presented in it's most simplistic form, i.e. in a simple list format.
Finally, go to the toolbar in SSRS and drag a 'Matrix' into the report. A Matrix table acts similar to a pivot table in Excel or a CrossTab query in Access that will display whatever's in the Dataset.