Setting Retrieval Argument at Runtime
Sergio Espallargas
Does anyone know how to set retrieval arguments to a datawindow at
runtime?
I tried this, but it doesn't work :(
s_test = dw_new.Modify( 'Datawindow.Table.Arguments= ("s_profile",
string)')
Thanks in advance for your help.
![Terry Voth [TeamSybase]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVklmaD3P7c9mYLj1EUbYO3kvYUxaVrJ1_UaYHgfBFyJ9WH=s40-c)
Terry Voth [TeamSybase]
entire syntax (Describe ('datawindow.syntax')), manipulate *that* (read:
non-trivial) and Create() with that.
It's far easier to modify the SQL syntax directly containing the values
for arguments you want to supply.
Good luck,
Terry [TeamSybase] and Sequel the techno-kitten
--
*********************************
PowerBuilder for $95? No.
Personal use PB Enterprise *AND* PocketBuilder *AND* DW.NET *AND* Sybase
IQ as
free benefits of an ISUG membership. See http://www.isug.com for details.
*** For a limited time, use promotion code MP20224C to get a $10 (USD)
discount
on a complete new or renewal membership
*********************************
Click once a day to help the hungry
http://www.thehungersite.com
*********************************
Newsgroup User Manual
=====================
TeamSybase <> Sybase employee
Forums = Peer-to-peer
Forums <> Communication with Sybase
IsNull (AnswerTo (Posting)) can return TRUE
Forums.Moderated = TRUE, so behave or be deleted
*********************************
Sequel's Sandbox: http://www.techno-kitten.com
Home of PBL Peeper, a free PowerBuilder Developer's Toolkit.
Version 3.0.02 now available at the Sandbox
PB Futures updated Apr 24/2006
See the PB Troubleshooting & Migration Guides at the Sandbox
^ ^
o o
=*=
Sergio Espallargas
kitten.com> wrote:
> Can't be done; it's not a modifiable attribute. You'll have to grab the
> entire syntax (Describe ('datawindow.syntax')), manipulate *that* (read:
> non-trivial) and Create() with that.
>
> It's far easier to modify the SQL syntax directly containing the values
> for arguments you want to supply.
>
> Good luck,
>
> Terry [TeamSybase] and Sequel the techno-kitten
>
> Sergio Espallargas wrote:
> > Hi everyone,
> > Does anyone know how to set retrieval arguments to a datawindow at
> > runtime?
>
> > I tried this, but it doesn't work :(
>
> > s_test = dw_new.Modify( 'Datawindow.Table.Arguments= ("s_profile",
> > string)')
>
> > Thanks in advance for your help.
>
> --
> *********************************
> PowerBuilder for $95? No.
> Personal use PB Enterprise *AND* PocketBuilder *AND* DW.NET *AND* Sybase
> IQ as
> *** For a limited time, use promotion code MP20224C to get a $10 (USD)
> discount
> on a complete new or renewal membership
>
> *********************************
> *********************************
> Newsgroup User Manual
> =====================
> TeamSybase <> Sybase employee
> Forums = Peer-to-peer
> Forums <> Communication with Sybase
> IsNull (AnswerTo (Posting)) can return TRUE
> Forums.Moderated = TRUE, so behave or be deleted
> *********************************
>
> Sequel's Sandbox:http://www.techno-kitten.com
> Home of PBL Peeper, a free PowerBuilder Developer's Toolkit.
> Version 3.0.02 now available at the Sandbox
> PB Futures updated Apr 24/2006
> See the PB Troubleshooting & Migration Guides at the Sandbox
> ^ ^
> o o
> =*=
Well, I guess I'd have to do it the hard way then. I want the users to
be able to use arguments on their where clause.
Thanks anyways for your input.
Best regards,
Sergio
Karla
"Sergio Espallargas" <serg...@gmail.com> escribió en el mensaje
news:1184092603.6...@q75g2000hsh.googlegroups.com...
Dave Fish [TeamSybase]
Where clause for the DataWindow at runtime by concatinating a string.
This is a whole lot easier than trying to create a DataWindow on the
fly with retrieval arguments.
Here is an example from the Modify function in the Help File:
Adding a WHERE clause The following scripts dynamically add a WHERE
clause to a DataWindow object that was created with a SELECT statement
that did not include a WHERE clause. (Since this example appends a
WHERE clause to the original SELECT statement, additional code would
be needed to remove a where clause from the original SELECT statement
if it had one.) This technique is useful when the arguments in the
WHERE clause might change at execution time.
The original SELECT statement might be:
SELECT employee.emp_id, employee.l_name
FROM employee
Presumably, the application builds a WHERE clause based on the user's
choices. The WHERE clause might be:
WHERE emp_id > 40000
The script for the window's Open event stores the original SELECT
statement in original_select, an instance variable:
dw_emp.SetTransObject(SQLCA)
original_select = &
dw_emp.Describe("DataWindow.Table.Select")
The script for a CommandButton's Clicked event attaches a WHERE clause
stored in the instance variable where_clause to original_select and
assigns it to the DataWindow's Table.Select property:
string rc, mod_string
mod_string = "DataWindow.Table.Select='" &
+ original_select + where_clause + "'"
rc = dw_emp.Modify(mod_string)
IF rc = "" THEN
dw_emp.Retrieve( )
ELSE
MessageBox("Status", "Modify Failed" + rc)
END IF
Regards,
Dave Fish
Sybase
Jerry Siegel [TeamSybase]
at a DW in source editor), so you would have to replace that entire "clause"
in the syntax. I haven't tried modifying datawindow.table, but it might be
easier than replacing the entire syntax. As Terry said, it's a lot easier to
replace the SQL using a custom WHERE clause, or as previous post suggested
put the DW in query mode and let the user supply criteria for any or all
columns.
"Karla" <Ka...@test.com> wrote in message news:4693db2d@forums-1-dub...
Jim Madderra
"Sergio Espallargas" <serg...@gmail.com> wrote in message
news:1184092603.6...@q75g2000hsh.googlegroups.com...
Sergio Espallargas
> Why?
>
> "Sergio Espallargas" <sergio...@gmail.com> wrote in message
>
> - Show quoted text -
Hey Mr. Dave Fish,
I appreciate your response; unfortunately modifying the
Datawindow.Table.Select would not resolve this problem. In addition, I
would have not posted this question if the answer could be found in
the PB help file.
Like Terry and Jerry say, I was finally able to accomplish this by
replacing the select part of the dw's syntax. I had to created it the
same way powerbuilder creates the select when arguments are present.
It was easy for to use PB syntax and just substitued the retrieve part
of the Table syntax. i.e.
Table (......
retrieve= "PBSELECT (VERSION(400) TABLE(...) COLUMN(...) WHERE(EXP1 =
~"...~" OP=~"=~" EXP2=~":EMP_NAME~") ARG(NAME="EMP_NAME", TYPE=string)
" arguments(("emp_name", string))
Recreating the retrieve part was the best fit for the solution to this
problem. My goal is to create a full dynamic DW painter where users
are able to create their own reports, so far I'm able to dynamically
create all different types of DWs, such as: tabular, grid, group,
graph, crosstab, free form, etc... ; I have also created a graphical
UI where user is able to select the tables, create joints, there are
tabs where the user could create the where clause, group, sort,
compute fields, etc... Now, I was able to add arguments to this
project where users can create their reports using arguments so that
the where clause is not fixed to certain value.
Thanks again guys
Best regards,
Sergio
Dave Fish [TeamSybase]
suggested, except you are modifying the psuedo-SQL syntax and the
approach I suggested would just add an where clause to the select
statement after calling SetTransObject. But hey I'm glad you got it
working.
Regards,
Dave Fish
Sybase
Terry Voth [TeamSybase]
> Datawindow.Table.Select would not resolve this problem. In addition, I
> would have not posted this question if the answer could be found in
> the PB help file.
Dude, chill. There are lots of questions posted here that have answers
in the PB help file. It's no crime.
Frankly, if I was looking at these answers at this point, I'd say mine
was more academic, and Dave's was more practical for the vast majority
of situations. To be honest, I'm still not sure how mine helped you more
than his (I don't understand the usage of the built DataWindows), but if
you're happy, that's what counts.
Good luck,
--
*********************************
PowerBuilder for $95? No.
Personal use PB Enterprise *AND* PocketBuilder *AND* DW.NET *AND* Sybase
IQ as
free benefits of an ISUG membership. See http://www.isug.com for details.
Josep
reports, ...
wouldn't InfoMaker be a possibility?
> On Jul 10, 6:49 pm, "Jim Madderra" <jmadde...@astound.net>
> > wrote: Why?
> >
> > "Sergio Espallargas" <sergio...@gmail.com> wrote in
> message >
> >
> news:1184092603.6...@q75g2000hsh.googlegroups.com
> .. >
> >
> >
Josep
etc...
wouldn't InfoMaker be a solution?
> On Jul 10, 6:49 pm, "Jim Madderra" <jmadde...@astound.net>
> > wrote: Why?
> >
> > "Sergio Espallargas" <sergio...@gmail.com> wrote in
> message >
> >
> news:1184092603.6...@q75g2000hsh.googlegroups.com
> .. >
> >
> >
Sergio Espallargas
Hey guys,
My previous posting was not intended to disrespect anyone. We are just
having a discussion. Right?
What I was saying is that just changing the where clause would not
work, beacuse you still need to let the DW know, some how, what the
arguments are in order for you to create the DW syntax. For instance,
when dynamically creating the DW syntax using the SyntaxFromSQL
function, the function would return an error if there is an argument
on the where clause (table.field = :arg_name) . I still wanted to get
the dw syntax, so before calling this function I add single quotes to
all the arguments, something like this (table.field = ':arg_name').
Later on, before the retrieve, I changed the retrieve part of the dw
syntax like I explained on my previous posting.
Best Regards
K R
Not sure you're understanding Dave's suggestion completely. When you
modify the WHERE clause, you are putting the argument(s) directly into the
sql (which PB does behind the scenes when you use arguments anyway). Kind
of like a "you say 1/2 dozen, I say 6" situation (depending on your bakery).
Since modifying the SQL is a little simpler, that's what more folks do. You
are really doing the same thing, just different approaches - it's all good!!
KR
Dave Fish [TeamSybase]
The approach I'm suggesting wouldn't use retrieval arguments at all.
Regards,
Dave Fish
Sybase
Sergio Espallargas
>
> - Show quoted text -
Better yet, I just tested it and it works. No need to change anything
on the SQL part of the DW syntax. I'm now just adding the arguments
attribute to the Table syntax and it does the same thing.
To better understand what I wanted to accomplish. Here is a part of
the dwsyntax that get's created at runtime:
release 10.5;
datawindow(units=2 timer_interval=0 color=1073741824 processing=0
print.margin.bottom=250 print.margin.left=250 print.margin.right=250
print.margin.top=250 print.preview.buttons=no )
table(
column=(type=char(10) update=yes key=yes updatewhereclause = yes
name=ac dbname="ac")
column=(type=char(10) update=yes updatewhereclause = yes
name=ac_type dbname="ac_type")
column=(type=char(10) update=yes updatewhereclause = yes
name=ac_series dbname="ac_series")
retrieve="SELECT
~"AC_MASTER~".~"AC~",~r~n~"AC_MASTER~".~"AC_TYPE~",~r~n~"AC_MASTER~".~"AC_SERIES~"~r~nFROM
AC_MASTER~r~nWHERE (~"AC_MASTER~".~"AC~" = :S_AC ) ~r~n"
update="AC_MASTER" updatewhere=1 arguments=(("S_AC", STRING)))
header(height=165)
detail(height=197)...
Like KR said "it's all good", although I'm not sure he understood the
problem.
Time to move on to the next subject.
Best regards
Sergio Espallargas
> AC_MASTER~r~nWHERE (~"AC_MASTER~".~"AC~" = :S_AC ) ~r~n"
> update="AC_MASTER" updatewhere=1 arguments=(("S_AC", STRING)))
> header(height=165)
> detail(height=197)...
>
> Like KR said "it's all good", although I'm not sure he understood the
> problem.
>
> Time to move on to the next subject.
>
>
> - Show quoted text -
I agree with you Dave, but the thing is that I wanted to dynamically
create a DW with retrieval arguments. So that when it gets retrieve,
it would ask the client to enter the values for the arguments.
Thank you for your time Dave,
Best regards.
K R
the syntax so that PB would prompt the user to enter the values for the
argument(s) when you call retrieve then maybe we would've understood what
you were trying to do. There's certainly more "elegant" ways of doing that
(which would allow you to get the values first so you could modify the where
clause), but you go what you needed. Maybe more info on the requirement
would help next time. Next...
KR
"Sergio Espallargas" <serg...@gmail.com> wrote in message
news:1184165357....@22g2000hsm.googlegroups.com...
> ~"AC_MASTER~".~"AC~",~r~n~"AC_MASTER~".~"AC_TYPE~",~r~n~"AC_MASTER~".~"AC_S胥RIES~"~r~nFROM
Paul Horan[TeamSybase]
news:1184165357....@22g2000hsm.googlegroups.com...
>>
create a DW with retrieval arguments. So that when it gets retrieve,
it would ask the client to enter the values for the arguments.
Thank you for your time Dave,
Best regards.
<<
What's the difference between that, and appending a "WHERE col1 = 'value1'
and col2 = 'value2' " to the end of your SQL statement with GetSQLSelect?
One way uses retrieval arguments (harder) and the other uses string
concatenation and SetSQLSelect() (easier).
Paul Horan[TeamSybase]
Terry Voth [TeamSybase]
no arguments are supplied to the retrieve.
Just my two cents,
Terry [TeamSybase] and Sequel the techno-kitten
--
*********************************
PowerBuilder for $95? No.
Personal use PB Enterprise *AND* PocketBuilder *AND* DW.NET *AND* Sybase
IQ as
free benefits of an ISUG membership. See http://www.isug.com for details.
Sergio Espallargas
com> wrote:
> "Sergio Espallargas" <sergio...@gmail.com> wrote in message
The whole idea is for the clients to be able to create their own
reports. Meaning, they are the ones who select the tables, create the
joints, create compute fields, use where clauses on their reports, or
what not. I was able to create this sort of a DW painter where the
client have a lot of flexibility to create their own reports. Now, I
just added "Retrieval Arguments" to this project, where client would
be able to add, edit, delete this arguments and use them as they
please in the where clause. Once they click on the preview/print
button, the program creates the report (dynamic datawindow) for them,
and of course if the used a retrieval argument on their where clause,
a window will popup asking them to enter w/e values to finally print/
preview the report.
Hope this is clear enough. Never thought that this was going to such a
hot topic.
Again thanks to all members of [TeamSybase] that added their thoughts
and subjections to this topic.
Best Regards
Chris Werner
comparatively difficult implementation to achieve a rather poor result.
Implementing the dynamic creation of a datawindow with retrieval arguments
is harder than extending the where clause of a given datawindow to set
some restrictions. What you get on the other hand is the standard retrieval
arguments dialog which isn't really nice and can't be extended. This dialog
shows column names (optionally prefixed by table names) as leading texts
for the inputs. It hasn't any formatting options for the input fields not to
speak
about date picker dialogs, drop down lists, checkboxes and so on. So it
*seems* to suggest itself to implement a dynamic dialog for the retrieval
arguments and to extend the where clause of the datawindow according to
the user input.
Just my 2 ct
Chris Werner
f+s software gmbh
"Sergio Espallargas" <serg...@gmail.com> schrieb im Newsbeitrag
news:1184181678.0...@o61g2000hsh.googlegroups.com...
Sergio Espallargas
> Maybe the misunderstanding is caused by the fact, that you've choosen a
> comparatively difficult implementation to achieve a rather poor result.
> Implementing the dynamic creation of a datawindow with retrieval arguments
> is harder than extending the where clause of a given datawindow to set
> some restrictions. What you get on the other hand is the standard retrieval
> arguments dialog which isn't really nice and can't be extended. This dialog
> shows column names (optionally prefixed by table names) as leading texts
> for the inputs. It hasn't any formatting options for the input fields not to
> speak
> about date picker dialogs, drop down lists, checkboxes and so on. So it
> *seems* to suggest itself to implement a dynamic dialog for the retrieval
> arguments and to extend the where clause of the datawindow according to
> the user input.
>
> Just my 2 ct
>
> Chris Werner
> f+s software gmbh
>
>
> - Show quoted text -
That, in fact, is what real programming is about my friend. The more
difficult for the programmer, the more easier for the client.
Best regards,
Sergio Espallargas
Chris Werner
> difficult for the programmer, the more easier for the client.
That's exactly the kind of generalization which I was risking to contradict
in my post. Where is PowerBuilders standard retrieval argument dialog
easier for the user than a self implemented one? Which advantage takes
the user of internal datawindow syntax with retrieval arguments? Is it
really pretty to have column and table names invented by techies as leading
texts for input fields? Wouldn't a simple date picker dialog or a drop down
list/datawindow make the dialog much more comfortable for the user? But no,
that can't be true because it is more difficult for the programmer to
implement
the setting of retrieval arguments at runtime. And that is because
PowerBuilder
offers an easy way to extend the WHERE clause of a datawindows SELECT
statement but doesn't offer a straight construct to change retrieval
arguments at
runtime. To my experience choosing the harder way doesn't redounds to the
users advantage everytime. But cultivates the programmers vanity sometimes.
;-)
Kind regards
Chris Werner
f+s software gmbh
"Sergio Espallargas" <serg...@gmail.com> schrieb im Newsbeitrag
news:1184249420.4...@g4g2000hsf.googlegroups.com...
Douglas
To quote Bill Gates, that could be 'the stupidest thing I've ever heard'. If
your client thinks that making your life miserable makes their life easier
then they too are idiots. I am at a loss for words, and that rarely, if
ever, happens.
"Sergio Espallargas" <serg...@gmail.com> wrote in message
news:1184249420.4...@g4g2000hsf.googlegroups.com...
K R
is a "real programmer" and is going to talk down to people who tried to help
him. I also liked the slap in the face where he says "Again thanks to all
remember this id if he's ever looking for help again. Looks like he doesn't
care what the screen that prompts the user for the arguments looks like or
care that he has no control over it. I was done with this thread but wanted
to respond when he was so condescending to Chris in particular, and every
non TS in general. If you ask for help, you are going to get advice
sometimes. Considering other people's designs/solutions is an attribute of
a real developer. Maybe so many suggested the same thing for a reason!!
my .02
KR
"Sergio Espallargas" <serg...@gmail.com> wrote in message
news:1184249420.4...@g4g2000hsf.googlegroups.com...
Sergio Espallargas
> "The more difficult for the programmer, the more easier for the client."
>
> To quote Bill Gates, that could be 'the stupidest thing I've ever heard'. If
> your client thinks that making your life miserable makes their life easier
> then they too are idiots. I am at a loss for words, and that rarely, if
> ever, happens.
>
>
> - Show quoted text -
Hi Chris, I agree with you in a way, but I think that you are missing
the whole purpose of the program itself. Picture this,
You have this program where like I have posted before the user is the
one who create's its own report, choosing tables, etc. Now, the user
also have the ability to save this report, and share it with other
users.
Let's say that the Maintenance Department Manager makes a report out
of the employee table and he puts in the where clause "department_id =
10" (10 = Maintenance), but he wants to share this same report with
the Transpotation Manager, the report would be useless for the
Transportation Manager since the report is fixed to a department
number, in this case 10. FYI, the creator of the reports is the only
one that have access to the report painter, so the Transportation
Manager could have not access to change the where clause, instead he
would just preview/print the shared report.
I dont see how just by changing the where clause, you would get the
same results. It could probably be done some how, don't have time to
think about it now, but I think would cost a lot more effort and DB
space, becuase you would have to save argument names, types, etc.
However, doing this the way I did it. Just saving the DW syntax would
do the trick, because the arguments are within the syntax.
Just my 2 cents,
Best Regards
Mike Niemann
I'll respond here... so that Chris, Douglas, and KR can see the response.
Sergio, if I may intervene as an interpretor... you may want to just leave
the comments to a "thanks", and ultimately post your final solution (if you
are proud of it).
Chris, Douglas, and KR... Is it possible that English is not this guy's
native language, and he meant to say something like "I don't mind doing some
heavy lifting if it will make things easier for my users". Maybe he could be
given a little slack.
Regards, Mike Niemann, PBBrowser Author
(just brownsing during lunch... sorry to jump in)
"Sergio Espallargas" <serg...@gmail.com> wrote in message
news:1184249420.4...@g4g2000hsf.googlegroups.com...
Sergio Espallargas
wrote:
> Sergio,
>
> I'll respond here... so that Chris, Douglas, and KR can see the response.
>
> Sergio, if I may intervene as an interpretor... you may want to just leave
> the comments to a "thanks", and ultimately post your final solution (if you
> are proud of it).
>
> Chris, Douglas, and KR... Is it possible that English is not this guy's
> native language, and he meant to say something like "I don't mind doing some
> heavy lifting if it will make things easier for my users". Maybe he could be
> given a little slack.
>
> Regards, Mike Niemann, PBBrowser Author
> (just brownsing during lunch... sorry to jump in)
>
>
> - Show quoted text -
Thanks!!!!