I have a user requirement to convert oracle standard report (Transaction Historical Summary)'s output into Excel
I have tried to change output to xml to get the xml tags so to make rdf but it ends in error.
What are the steps to convert a standard report's output to excel?
You'd use Report Builder's DESFORMAT=SPREADSHEET parameter; it works for Reports 10gR2 onwards.
Here's a tutorial which shows how to do that: "Building a Report for Spreadsheet Output" (https://docs.oracle.com/cd/B14099_19/bi.1012/b13895/orbr_paptoexcel.htm).
It doesn't make sense to copy/paste all those steps over here, so - have a look, follow the instructions.
If you're on lower version, you'd create a CSV (comma-separated-values) file (choose any delimiter you want, such as comma or semi-colon). Although it is not a XSL(X) file, Excel is capable of opening it nicely.
Related
I have a requirement where I need to programmatically download the BIRT report in excel (xlsx) format and for a specific page range. Like (5-10).
By default it is generating the excel sheet with all the rows. Can anyone please help here.
Note: I am using the org.eclipse.birt.runtime4.4.1.jar.
Regards,
Sandip Mohapatra
It doesn't make sense, because XLSX is not a page-oriented format.
If instead you want to generate an XLSX with only the rows for records e.g. 51-100 then you should use a LIMIT clause in the SQL statement or something like that.
When exporting a query result from SQL Developer to Excel (format xlsx) the dates in my query seem to be exported as text.
I need to filter and sort this data in Excel.
After exporting Excel gives me the option to convert the dates to 20XX, but is there a way to format my dates fields in such a way that I can sort straight away?
My current date format in Preferences is DD-MON-RR
I have a workaround; instead of exporting directly to XLSX, export result as a CSV. Excel is capable of opening such files and - guess what - sorting by date column works fine (I've just tested it). Then, if you want, save file as XSLX.
Yes, I know, this is impracticable, but that's the best I know right now.
I would ask about capability to change the filed datatype from Single line to Multiline without delete this field.
Actually the CRM form editor is disable the data type option set after filed created, so I think I have to change the data type via Database
but I need to know if is it possible to do that, and if we change the data type from the database is it will change the filed from single line shape to multiline in the form.?
because my CRM is online so I need confirm is it possible, to ask Microsoft to do it for me.
Best regards .
It is not possible to convert a single line text field to a multi-line text field. Instead you should create a new multi-line text field and move the data from the old field to the new field.
If you were on-premise, you should not be making direct changes to the database (and there is no way Microsoft would be doing so for you online):
Modifying tables, stored procedures, or views in the database is not
supported.
Yes, as Henrik mentions, it's not possible, but tools can make it appear to be for all practical purposes ;)
The Attribute Manager (it's a plugin for the the XrmToolBox) will do this for you. It's in beta, so don't run it in prod without testing it in another environment first.
Just select your field, check Convert Attribute Type (optionally check Migrate Data if you want it migrated) and execute. You'll need to do it in each environment.
I have this csv file that I would like to parse with Ruby. The file's data is a cluster with commas and new lines in the fields but Excel still reads it properly. If the file could be exported from excel using the unit and record separators as the delimiters for the columns and rows, I'd be golden.
Anybody know how to specify those characters in excel? Thanks!
Use Ruby CSV with this option:
:col_sep
The String placed between each field. This String will be transcoded
into the data’s Encoding before parsing.
See more here: http://ruby-doc.org/stdlib-2.0.0/libdoc/csv/rdoc/CSV.html
I ended up having Google Sheets export the file as json. Steps I followed here There were 10,000 records and the browser tab crashed when it tried to do all of them. So I had to piece meal it. I'm sure there's a better way to do it.
This is my first attempt to create a Visual Studio 2008 report using parameters. I have created the dataset and the report. If I run it with a hard-coded filter on a column the report runs fine. When I change the filter to '?' I keep getting this error:
No overload for method 'Fill' takes '1' argument
Obviously I am missing some way to connect the parameter on the dataset to a report parameter. I have defined a report parameter using the Report/Report Parameter screen. But how does that report parameter get tied to the dataset table parameter? Is there a special naming convention for the parameter?
I have Googled this a half dozen times and read the msdn documentation but the examples all seem to use a different approach (like creating a SQL query rather then a table based dataset) or entering the parameter name as "=Parameters!name.value" but I can't figure out where to do that. One msdn example suggestted I needed to create some C# code using a SetParameters() method to make the connection. Is that how it is done?
If anyone can recommend a good walk-through I'd appreciate it.
Edit:
After more reading it appears I don't need report parameters at all. I am simply trying to add a parameter to the database query. So I would create a text box on the form, get the user's input, then apply that parameter programmatically to the fill() argument list. The report parameter on the other hand is an ad-hoc value generally entered by a user that you want to appear on the report. But there is no relationship between report parameters and query/dataset parameters. Is that correct?
My last assumption appears to be correct. After 30 years in the industry my bias is to assume a report parameter actually filters the SQL data using the given parameter. This is not the case with .rdlc files used by Report Viewer. These report parameters have nothing to do with fetching data. Sounds like this was a design decision on Microsoft's part to completely separate the display of data from the fetching of data, hence, Report Viewer has no knowledge of how data may be fetched. Best way for me to conceptualize this dichotomy is to think of Report Parameters more as Report Labels, quite distinct from the dataset query parameters.