How to export data from datawindow to Excel in PowerBuilder? - powerbuilder

I want to export data from data window into excel sheet with customized column order, what is the syntax for that?
For ex: In my data window I have data in the order ID/Name/DOB/City. But I want to import in order Name/ID/DOB/City

There’s nothing automagic that can do that. Two options that I can think of:
OLE the data to Excel
Create a second DataStore with the data set columns in the order you want, then copy the data across, one column at a time using dot notation, and SaveAs() the second DataStore.
In terms of runtime performance, I’d expect the second option will be faster, especially as the data set gets larger.
Good luck.

There are a few ways to do this. One way is via a second datastore which is populated via the ShareData method. This second datastore would use a datawindow object set up with the same columns as in the original datawindow but in the order you wish to have them in the export.
Code example for this:
int li
li = dw_primary.Sharedata(ds_excelexport)
IF li > 0 THEN
dw_excelexport.Saveas("c:\temp\export.xls",Excel!,TRUE)
END IF

Related

How to use Select INTO statement when table columns keep changing?

I want to use Select INTO statement for a table that keep changing number of columns.
Select * FROM myTable returns me the desired output but i dont know how to use same select statement in powerbuilder with INTO because i dont know how many columns will be there in myTable and i dont even know what will be the names for those columns.
Names and numbers of columns varies so i think array can be used but how to use it i have no idea. Is it possible? is there any other way to solve this problem?
PowerBuilder 12.5 / MSSQL Server 2008
Use select * from myTable as your SQL string and create a DataWindow dynamically . You can use the Describe() functions to get the column count (and optionally names, database column source, data types), and GetItem*() with column numbers to retrieve the data.
Please keep in mind that while preparing for change sounds good, like all design choices, it comes with trade offs. In this case, consider performance (creation of the DW requires extra trips to the database) and maintainability (troubleshooting a problem involving a dynamic DW is much harder than a static one; you’ll need to staff up with more advanced programmers). You might want to consider how often the table will change, and how likely it will be that the user will be so happy with the application that the occasional release with other changes would be a bad thing. (Not that I’ve never done this, but over 25 years in PB and dozens of clients, I can probably count the times on the fingers of one hand. For me, it’s a carefully considered last resort.)
As an extension of Terry's answer you can use dot notation to determine the specifics on a datawindow object's data after retrieval. So after you have dynamically created the datawindow and retrieved the data you can assign the data values to a structure.
From the PowerBuilder help:
This example assigns all the data in dw_1 to the Any variable la_dwdata. The value assigned to la_dwdata is an array of data structures whose members match the column datatypes:
any la_dwdatala_
la_dwdata = dw_1.Object.Data
You can use the Classname() method to determine the datatype of each column if needed.

Sorting on hidden data

Is it possible to have data in a Handsontable sorted by a field which is not displayed? I have a grid of data which I would like to display that contains a column called "sortOrder", but I don't want to display this.
The sorting needs to be done client side because events are coming in over web sockets and need to be reflected in the table.
If you're not showing the column then I assume you're not expecting the user to be able to manually sort by this hidden column. Therefore, why don't you simply sort your data array with native JS? At any point during execution you could have a function which sorts by this hidden column and then just don't render this in your Handson definition.
So yes, the answer is it is possible. The not showing of a column is as simple as defining the columns option and not including a column for this hidden value.

Changing columns order on export to CSV from SSRS 2008

We have a report developed in another tool that the user exports to Excel to manipulate the data. In the old tool, the columns are being saved in the same order as the dataset returned by the stored procedure. But in SSRS the columns sort is changed to the order that they are displayed on the screen. The user is a nut case and can't convince her to change the order of the columns on the screen report to match her old report sort, but on the other hand does not want to adapt to the new column order. Unfortunately the easiest solution (i.e. replacing the user :-)) is not implementable. Is there a property that I can use to change the sorting on the columns when they are exported. Without knowing much about it, I imagined ZIndex would have done something like that. But it is set to 0 and disabled, so I can't change it's value.
Thanks
I know it's years later but for the benefit of anyone who is in this predicament, a similar idea: in the same report, you create another tablix that will be your "output" tablix, where you arrange things as you please using the same dataset. Make this tablix with visibility hidden, and set it to "output" as necessary. Turn off all outputs from the first tablix. So you have basically a ghost tablix that only works when you export to csv.

How to count the datawindow computed fields dynamically?

Dynamically how to count the datawindow computed fields and DDDW Fields? is there any functions in PowerBuilder?
otherwise we need to take DW Syntax? then parsing...
You want to start with a dw.Describe ("datawindow.objects") to get a tab delimited list of all objects on the DataWindow's UI surface. Parse apart this list, then for each do a dw.Describe (as_ObjName + ".type") and test for the value "compute".
Good luck,
Terry.

How to convert external DataWindow to SQL Select DataWindow

I am trying to make ID badge App. The user design the card after that create table for that card for data entry. So, I create dynamically external DataWindow after accepting the fields from user (column, text, line, picture, checkbox, radiobutton, barcode, ...etc) . Now I need to convert this created DataWindow (on-the-fly) to SQL SELECT DataWindow after I create table for that purpose.
How do I convert ?
There is no automated mechanism to convert an external datawindow into a SQL Select. If you know your way around the .srd file format, it can be done manually, but its much easier to recreate a new dw from scratch.
-Paul Horan-
SAP
What I'd do is create a new DataWindow with the SQL you want; don't bother tweaking the UI (I'm assuming that's what you want to salvage from the original DW). Take the table() portion of the new DW and replace the table() portion of the original DW. Be sure you're matching parentheses properly; there are a lot of embedded sets of parentheses within the table() portion. If in doubt, use something like NotePad++ to find the matching parentheses for you.
This sounds easy, and that was the easy part. The real kicker, depending on how big the data set is, is to make sure that the data set matches, element for element, data type for data type. Off by one, and you'll have screwed this up in ways that are inconceivably difficult to track down after the fact.
Good luck,
Terry.
I missed the "on-the-fly" part the first time through, but the same advice applies; you'll just have to do it programmatically, which is harder still. Finding the matching paren is challenging enough when you don't have to ignore parens that might be contained in the SQL SELECT statement, let alone in other strings like column values expressions. It's possible, just has a lot of edge cases to test that are hard to anticipate, like what happens when a string in the SELECT statement has an opening paren and no closing paren? Then matching data types has to be done programmatically, which in theory means parsing apart the column portions of each DW and comparing the data type. In practice (haven't done this, just tossing up an idea), you could just Create() with both syntaxes and see if a ShareData() between the two fails or not. (ShareData() allows some flexibility, e.g. integer and long, and I have no idea if those differences will cause you problems in other areas that you're trying to do this.) Of course, that might beg the question: Why not just create two sets of DW syntax, one external and one SELECT, and do a ShareData() between them?
You'll find it much simpler to create the table first, then create the DataWindow from the SQL. You'll be able to use most of the code you already have to create/modify the visual part of the DataWindow.
I recommend you think very carefully about this design, because sooner or later a user is going to want to make a change to the data on an existing badge design that can't be done without dropping and recreating the table and migrating the data. A good rule of thumb is to never let the end user design the database. I would create a table for each data type you are going to support and link them to the badge with an identifer for the attribute. The only thing the user does is add attributes of the available data types, give them names, and stick them on a badge. Keep your external DataWindow and use DataStores for each supported attribute type. If you use the attribute name as your external column name, you can easily write generic code to populate the badge from the attributes on retrieve and copy the attributes back to the DataStores to save. If you will take a look at pfc_n_cst_dwsrv.of_populatedddw (the no-parameter version) you will see the basic idea, except you will look at the column's datatype and dispatch a request to the DataStore that handles that data type, giving it the row, and column name (which is the attribute name) to populate. Saving works the same way except you give the DataStore the value to set back to the DataStore. You don't need to worry about whether the data changed, because the DataStore is smart enough to tell if it's the same. If you use PFC you can just set the update list to your DataStores and PFC will take care of them for you (you would use n_ds for the DataStores in this case). You will also need to set the badge id of new rows in the DataStores. You can use the n_ds's pfc_updatePrep event for that.

Resources