Is there an effective and/or fast way to show Html entities like & or ë as & and ë in an report viewer's parameter drop down list?
I have html encoded values in the database and now I need to show the original value in parameter drop down list
Or does MSSQL have an equivalent for this?
SQL Server doesn't have a built-in HTML decode function. Your options as I see it are
A series of REPLACEs as long as Earth to Mars
A CLR module as a SQL Function (I would use this)
Programming change to store another column with the un-encoded html string when inserting
To not loose any performance on the reporting, the users must change these characters in the GUI in order not to see them anymore...
No other suitable solution found for this situation. An mass update on all text columns was an other solution as well, but not really necessary.
Related
I'm rewriting an older-than-dirt MFC application, ripping out the old MFC-based DB code and re-working queries to make it run faster. This code works with a MS Access 2003 .mdb file.
The old code used the convenience functions like RFX_Bool, RFX_Long, RFX_Int to read from the records. These are nice, and I am reading about binding in ODBC using SQLBindCol to set the bindings ahead of time to avoid that extra processing time for each row. This is great, but I see SQLBindCol only takes the column number, not the name. What if I want to bind using the column name like with the RFX_* functions? SQLDescribeCol gives the column names, but it doesn't have the "full" name, i.e. [Table/Alias].[Column]. Some of my queries involve JOIN'ing the same table multiple times with aliases, so I can't bind the column by the column name alone. If I plug my query into Access, the Datasheet view shows the alias in the column name. I'm currently using my connection string with Driver={Microsoft Access Driver (*.mdb, *.accdb)}, if it matters.
tl;dr How do I do MFC's RFX_*(fieldExchange, L"[Table].[Column]", &variable) in the modern ODBC API?
OK, I think I understand what the RFX functions are doing now, and I think I know what I need to do.
The MFC ODBC classes construct your query programmatically, so after starting with SELECT, UPDATE, etc, every call to RFX_* simply appends the field name to the query, then ties a reference to your variable to the column index, which it increments after every call. So I just need to append my fields to my queries with a helper function the same way MFC does, in order to bind my pointers in the same way MFC does.
Hopefully this is helpful to somebody.
I have a SQL View that I'm working on that spits out some important information for my boss's boss's boss. The view includes a field called Item ID, which can be in several different formats.
Here are some examples (that may or many not be made up to protect the innocent):
ATS-LC-PLN-RT-RH-0.3125-18-3X2.125X1.5-1
012345.012345
01234567.0123
123456789012
000000.000000
000000.000002
I'd like to take the view and use it to (eventually) produce an excel spreadsheet, but I'm not confident that there's a way to format this column in a way that will work for all of these different Item ID's.
When playing around with Excel, these numbers drop their trailing zeroes and switch to scientific notation, among other shenanigans. I just need to format this column in a way that will preserve the Item ID.
If you know of a way to programmatically create an excel spreadsheet in a way that allows me to assign a format based on the data in the cell, that would work great. The problem that I'm mainly suffering from is that this spreadsheet naturally has hundreds of lines, soon to be thousands, and there's no feasible way to hand-format these lines one at a time on a daily or weekly basis.
I've got SQL-Server 2014 and Excel via Microsoft Office Standard 2013, which may offer more options.
Permit me to suggest another way of framing your issue. I don't think you really want to analyze (either manually or programmatically) each item ID and determine whether it is an integer, a decimal, or alphanumeric text. Since your item ID data varies, the only Excel formatting that will work for all of your cases is 'Text.' So my suggestion is look for a way to automate the export of your data to Excel while making sure that the formatting in Excel is set to 'Text' for all cells to contain your item ID data. As you've noticed, if you are pasting data in Excel, if the target cells are not first set to 'Text' formatting, Excel will make its own 'corrections' to each pasted value, including removal of leading and trailing zeros.
The best solution is to use SQL Server Reporting Services (SSRS). You can set the field formatting in SSRS, and then (if you choose) automate the export of your data to Excel by calling the report server by URL with &rs:Format=excel. (There is learning curve for SSRS but if you plan to continue doing things like this, it will be worth it.)
Other options
The easiest manual option is to 1) export the data to .csv format, 2) Open Excel and use the Text Import Wizard, and during Step 3 make sure to click the data column and then choose 'Text' as the data format. (You could automate this somewhat with an Excel VBA macro.)
The most complicated method involves programming using Excel VBA and ADO to automate the connection and querying of the data from your database view, and then rendering that data to a spreadsheet, using VBA to set the formatting to 'Text.'
I have dozens of SSRS Reports and the corresponding stored procedures that I am slowly cleaning up and optimizing, I am finding a number of data sets that have extra fields that are not used in the actual report, they are usually the result of a SELECT * that is slowing down the SP end of things significantly in a few places.
I am wondering if there is a quicker way to see which fields from the datasets are used/unused to more efficiently clean up the stored procedures. It seems like clicking through to each <<expr>> and checking them off is a ridiculous way to go about this.
I'll tell you, I wish I knew a tool that simplifies this for you.
And I don't off the top of my head.
But for sure I know you can search the text of the rdl and find these details.
I do this often when troubleshooting problems with existing reports (or SSIS packages).
The .rdl files are human-readable xml.
You can open any one file in a text editor and search the text - even Visual Studio if you "Open File" rather than use the Report project.
Given that, of course you can write a routine in your preferred programming language that
finds the query or proc in the data source of the Report
runs it (as metadata only) to get all the columns
search for each one in the text of the rdl
you can be more specific if you use xml queries to limit
the search to more realistic targets like display box Data Sources
Sorry I don't have a more convenient answer like an existing tool.
If I remember, I may look for one because this is a big problem for "corporate coders" like us.
If I can't find one, maybe I'll write the script in .net and come back and post it :)
Yes you can ! Use the following steps
right click the rdl file and
click the View Code . This will be an XML format
CTR + F to get a search text box
Enter the name of any field in the text box.
Use the Forward Arrow icon to see the number of occurrence of the searched field name
If the text field is in the dataset and Tablixcell value, then it shows it's being used in the report
If the text field is only in the dataset and not any tablixcell value, then it's not being used in the report.
what is the best way to store long texts (articles) in a database? it doesnt need to be searchable.
i want to allow ppl to read the first chapter of every book in my bookstore. dumping it into a database field makes it difficult to style paragraphs using css..
EDIT: access database
If it is sql server 2005 USE VARCHAR(MAX)
EDIT,
It seems he saif access,
so i would go with memo
Up to 63,999 characters. (If the Memo
field is manipulated through DAO and
only text and numbers [not binary
data] will be stored in it, then the
size of the Memo field is limited by
the size of the database.)
or OLE Object (if you can)
An object (such as a Microsoft Excel
spreadsheet, a Microsoft Word
document, graphics, sounds, or other
binary data) linked (OLE/DDE link: A
connection between an OLE object and
its OLE server, or between a Dynamic
Data Exchange (DDE) source document
and a destination document.) to or
embedded (embed: To insert a copy of
an OLE object from another
application. The source of the object,
called the OLE server, can be any
application that supports object
linking and embedding. Changes to an
embedded object are not reflected in
the original object.) in a Microsoft
Access table.
Up to 1 gigabyte (limited by available
disk space)
you have several options:
store it as a long single string with no formatting, which will look bland on the screen.
store it as a long single string with embedded html and css, which will be a bad choice if you ever want to make your site have a different look/feel.
normalize it so you have tables to store books, chapters, paragraphs, etc. you could then format and style the text as you load it into the application.
The main difference between long text (CLOB / TEXT / VARCHAR(MAX)) and long data (BLOB / IMAGE / VARBINARY(MAX)) is that the former is subject to character set conversions while the former is not.
If you need to make character set conversion on the database side, use CLOB and similar.
If you always want to retrieve your data as you atored it, byte-to-byte (as opposed character-to-character), use BLOB and similar.
I don't know which database you're using, but if text doesn't need to be searchable, then you can simply store the HTML formatted text (for instance, value coming from an FCKEditor or components like this). If you need also searchability, then you can store both HTML an plain text in two separated fields.
Fields can be nvarchar(MAX) if you use MS SQL Server 2008 or any equivalent datatype on other databases.
EDIT:
Seems you're using Access, so go for Memo data type!
If you decide to store HTML, consider to store only a generic markup (div, p) to divide your text, than later apply CSS formatting, wrapping stored text within another div specifing formatting classes for children elements.
I wouldn't store any of the documents in the database, but store the data in files in the file system, and the only thing that's in the database would be a pointer to the data files.
You don't give any details in your question that would suggest any need whatsoever to store the documents in the database itself.
And there are very few circumstances where it's advantageous.
Use a CLOB.
For SQL Server
TEXT / NTEXT for SQL Server 2000
VARCHAR(MAX) / NVARCHAR(MAX) for SQL Server 2005 onwards
I would propose storing the first chapter as pdf file. This is secure and allows for good formatting. Then use a blob, clob, varchar, or text field depending on your product (see the other answers).
Or you could use images and look into something like amazone's "look inside". It would work with the same db techniques.
Alternatively you could use something like markup.
I personally do not like to put html in my database. Even if it is only for output. Too easy to put in some javascript. But maybe I'm just too cautious.
The following applies to Jet 4.0 only, being the version of the Access Database Engine in the era Access2000 to Access2003 inclusive:
I wouldn't store any of the documents in the database, but store the data in files in the file system, and the only thing that's in the database would be a pointer to the data files.
You don't give any details in your question that would suggest any need whatsoever to store the documents in the database itself.
And there are very few circumstances where it's advantageous.
If you are using ACE, being the version of the Access Database Engine in the Access2007 era, the Attachment data type would be an option, however I don't really know how it works, I've never used it so I can't recommend it nor say whether it's better or worse for this purpose. I'm also wary of new data types in the first release of a major version of the Access Database Engine. I just remember all the issues with byte and decimal fields at the introduction of Jet 4 and don't want to commit to something that may never work properly. The Attachment type in the ACCDB format was introduced for Sharepoint compatibility, and that outside dependency is something that gives me pause. Will the ACCEDB data type change someday if Sharepoint changes the way it works? I'm not sure I'd want to take that risk.
Put it in a TEXT field, and put it with their <p> so you'll be able to style paragraphs.
As it doesn't need to be searchable, it won't impact your sql performance.
I am going to design a report using SSRS 2005. Is it possible to have the selection of dataset done dynamically?
Let's say I am going to have two tables, where the first one is the summary and the second is the detail data. One of my parameters (with values Summary and Detail) will determine which version of the report is to be displayed. Can I have two different datasets, and while clicking the view report button in parameter view dialog (or before) set which dataset which will be used?
You can use the single data set by using switch statement some thing like this:
You can type this in data tab but the results can be seen only in preview tab, but not the data tab like regular queries.
=Switch(Parameters!ToDecide.Value = "Summary",
"Your query for Summary",
Parameters!ToDecide.Value = "Detail",
"Your query for Detail")
Make sure you don't have any excess spaces with in the query(not more than one space where needed)
Both the queries should return the values required by the Table in Layout.
You'll probably have to have 2 pairs of table contained in, say, a rectangle, and hide the unused one (at the container level). Or use subreports.
If you find a way to switch datasets, then you'll have to make sure that all columns are the same as well as making sure that any functions using the DataSet as a scope parameter are changed too... which makes me think it just isn't supported.
You might want to try using a single dataset and having a summary and detail data region (table, list, etc.) in the report, one of which is visible and one of which is not. In this scenario, the dataset is only evaluated once and you are still meet your requirement.
Hope this helps,
Bill
It would be easier to create and maintain if you have two separate tables and hide one or the other depending on the choice made.
I haven't tried this, but I think another possibility would be to use three reports: a container, a summary subreport, and a detail subreport. Switch between the subreports according to the choice.
There is a performance gotcha to the first implementation though. SSRS will try to fill every DataSet in the report when it loads, even ones that are not used in the report's output or by other DataSets or expressions. In other words, just because you're displaying the summary report, doesn't mean that you're not asking the database to fill out your detail data as well.
There is a workaround that can improve the performance a bit, but will still end up with a trip to the server. The hack is to set a flag parameter to determine whether or not the query should actually return any real results or if it should just return the columns you want.
You may try adding condition that depends on a cetain parameter to execute. Then from there, You may use different data set. Assuming that you'll use it on separate hidden tablix.