Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

dynamic datawindow reports

3 posts in Commercial ISV's Last posting was on 2009-03-10 15:43:14.0Z
M. Searer Posted on 2009-03-10 14:29:04.0Z
From: "M. Searer" <nospam@nospam.com>
Newsgroups: sybase.public.commercial-isv.general
Subject: dynamic datawindow reports
Lines: 110
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49b67930$1@forums-1-dub>
Date: 10 Mar 2009 06:29:04 -0800
X-Trace: forums-1-dub 1236695344 10.22.241.152 (10 Mar 2009 06:29:04 -0800)
X-Original-Trace: 10 Mar 2009 06:29:04 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:274
Article PK: 103989

thread restarted from the powerscript forum...
last post from...Chris Werner

>>>computers will be so fast that the creation overhead is acceptable.
> Is this not the case now? I would have guessed that with dynamic creation
> of the datawindows syntax stored in a database that it would be fast
> enough.

You may be right about that. When I was implementing the framework
that wasn't the case but yeah ... meanwhile. Have never checked that
because it is comfortable to write dw_1.dataObject = ls_tmplFileName
instead of fileOpen() ... fileRead(..., ls_sntx) ... fileClose() ...
dw_1.create(ls_sntx)
and checking the result and coding error messages. Okay, that would be
only one method which is called then instead of the dataObject assertion.
I'm looking forward to check and implement that some month after PB12
is released.

> Are you doing this only for reports, or for data entry entry screens too?

When I was designing the framework I thougt about reports only but
since then many things changed and I use that for simple single table
update screens too. At the time being I'm in process to extend it for
simple types of multi table updates (in the loaded data must be a one
to one relation between the updateable tables). But that's kinda expert
modus. ;-)

> I update (and allow users to update via infomaker) reports via a .pbl
> since datawindows don't need to be compiled.
> This requires the whole pbl to get copied which I do at start up.

Yes, that's a good solution too. To be honest (customers please stop
reading here) one reason to go along the way I choosed was to show
the magic how an application changes while I'm on the help desk
phone and the customer asks for a change of a report he is seeing
right in this moment. It is really enjoyable on both sides of the phone
line when I say "Click refresh and look if the new design is what you're
after". Another feature is that Infomaker is integrated in our framework
so when you are looking at a screen and want to change it, you do
that with one click on the context menu, find yourself in Infomakers
report painter having loaded the report. Change it, save it, see it. Release
it - all users see it from now on. But my favorite feature is PB catalog
integration: After changing a report the appropriate properties of all
columns are parsed and written back to the PB catalog tables. When you
use this columns in another report its properties (column header, font
settings and so on) are already set for you. Okay, even if I'd really like
to continue this I'm going to think about how to withstand the actual
economic situation. But that's no discussion for this forum.

Best regards

Chris



"M. Searer" <nospam@nospam.com> schrieb im Newsbeitrag
news:49b55e18$1@forums-1-dub...
>>>computers will be so fast that the creation overhead is acceptable.
> Is this not the case now? I would have guessed that with dynamic creation
> of the datawindows syntax stored in a database that it would be fast
> enough.
>
> Are you doing this only for reports, or for data entry entry screens too?
>
> I update (and allow users to update via infomaker) reports via a .pbl
> since datawindows don't need to be compiled.
> This requires the whole pbl to get copied which I do at start up.
>
> regards,
> mike
>
>
> "Chris Werner" <cwAT{PleaseNoSpam}f-s.de> wrote in message
> news:49b4f942$1@forums-1-dub...
>> Actually I cache only the syntax, not the data. But this
>> is only because the data caching isn't used yet by the
>> users. If the report would contain data, that would also
>> be cached. On the other side I believe if the caching
>> would widely be used for data too I'd to change the
>> framework because data changes much more often
>> then syntax.
>>
>> The reason for caching is (indeed) UI performance.
>> When the user chooses a certain view (and she does
>> that all the time because our user interface framework
>> is based on this technique almost completely) a simple
>> check against the database determines if the syntax in
>> the database is newer than that one in the PSR file.
>> If it isn't (and this is the mostly the case) the dataobject
>> is linked to the PSR file on the local disk which is as
>> fast as having it in the PBD. Otherwise the PSR file
>> is refreshed prior to linking the dataobject to the PSR
>> file. So I'm saving not only the datawindow creation
>> overhead but the time to select and download it from
>> the database too.
>>
>> You are right, PSR seems to go away with PB 12
>> like some other techniques we've used in the past.
>> What can I say? PB 12 is announced for Q1 2010
>> (or is it H1 2010 meanwhile?). I'm not in a hurry
>> to use a new PB version once it is released. So I
>> conjecture if I'll be contrained to use PB 12 sometime
>> computers will be so fast that the creation overhead
>> is acceptable.
>>
>> Best regards
>>
>> Chris Werner
>> f+s software gmbh
>


Randy Posted on 2009-03-10 15:20:12.0Z
From: Randy <CGreenwellAtsparusaDotcom>
Reply-To: CGreenwellAtsparusaDotcom
Organization: SPAR Associates, Inc
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
Newsgroups: sybase.public.commercial-isv.general
Subject: Re: dynamic datawindow reports
References: <49b67930$1@forums-1-dub>
In-Reply-To: <49b67930$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49b6852c$1@forums-1-dub>
Date: 10 Mar 2009 07:20:12 -0800
X-Trace: forums-1-dub 1236698412 10.22.241.152 (10 Mar 2009 07:20:12 -0800)
X-Original-Trace: 10 Mar 2009 07:20:12 -0800, vip152.sybase.com
Lines: 125
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:275
Article PK: 103992

Chris,

How do you handle major changes to DWs when you upgrade the client. For
example, table changes. What happens to all of the DWs the customer
changed and they need to be updated with new columns or old columns are
deleted?

Curious...

Randy

M. Searer wrote:
> thread restarted from the powerscript forum... last post from...Chris
> Werner
>
>>>> computers will be so fast that the creation overhead is acceptable.
>> Is this not the case now? I would have guessed that with dynamic
>> creation of the datawindows syntax stored in a database that it would
>> be fast enough.
>
> You may be right about that. When I was implementing the framework
> that wasn't the case but yeah ... meanwhile. Have never checked that
> because it is comfortable to write dw_1.dataObject = ls_tmplFileName
> instead of fileOpen() ... fileRead(..., ls_sntx) ... fileClose() ...
> dw_1.create(ls_sntx)
> and checking the result and coding error messages. Okay, that would be
> only one method which is called then instead of the dataObject assertion.
> I'm looking forward to check and implement that some month after PB12
> is released.
>
>> Are you doing this only for reports, or for data entry entry screens too?
>
> When I was designing the framework I thougt about reports only but
> since then many things changed and I use that for simple single table
> update screens too. At the time being I'm in process to extend it for
> simple types of multi table updates (in the loaded data must be a one
> to one relation between the updateable tables). But that's kinda expert
> modus. ;-)
>
>> I update (and allow users to update via infomaker) reports via a .pbl
>> since datawindows don't need to be compiled.
>> This requires the whole pbl to get copied which I do at start up.
>
> Yes, that's a good solution too. To be honest (customers please stop
> reading here) one reason to go along the way I choosed was to show
> the magic how an application changes while I'm on the help desk
> phone and the customer asks for a change of a report he is seeing
> right in this moment. It is really enjoyable on both sides of the phone
> line when I say "Click refresh and look if the new design is what you're
> after". Another feature is that Infomaker is integrated in our framework
> so when you are looking at a screen and want to change it, you do
> that with one click on the context menu, find yourself in Infomakers
> report painter having loaded the report. Change it, save it, see it.
> Release
> it - all users see it from now on. But my favorite feature is PB catalog
> integration: After changing a report the appropriate properties of all
> columns are parsed and written back to the PB catalog tables. When you
> use this columns in another report its properties (column header, font
> settings and so on) are already set for you. Okay, even if I'd really like
> to continue this I'm going to think about how to withstand the actual
> economic situation. But that's no discussion for this forum.
>
> Best regards
>
> Chris
>
>
>
> "M. Searer" <nospam@nospam.com> schrieb im Newsbeitrag
> news:49b55e18$1@forums-1-dub...
>>>> computers will be so fast that the creation overhead is acceptable.
>> Is this not the case now? I would have guessed that with dynamic
>> creation of the datawindows syntax stored in a database that it would
>> be fast enough.
>>
>> Are you doing this only for reports, or for data entry entry screens too?
>>
>> I update (and allow users to update via infomaker) reports via a .pbl
>> since datawindows don't need to be compiled.
>> This requires the whole pbl to get copied which I do at start up.
>>
>> regards,
>> mike
>>
>>
>> "Chris Werner" <cwAT{PleaseNoSpam}f-s.de> wrote in message
>> news:49b4f942$1@forums-1-dub...
>>> Actually I cache only the syntax, not the data. But this
>>> is only because the data caching isn't used yet by the
>>> users. If the report would contain data, that would also
>>> be cached. On the other side I believe if the caching
>>> would widely be used for data too I'd to change the
>>> framework because data changes much more often
>>> then syntax.
>>>
>>> The reason for caching is (indeed) UI performance.
>>> When the user chooses a certain view (and she does
>>> that all the time because our user interface framework
>>> is based on this technique almost completely) a simple
>>> check against the database determines if the syntax in
>>> the database is newer than that one in the PSR file.
>>> If it isn't (and this is the mostly the case) the dataobject
>>> is linked to the PSR file on the local disk which is as
>>> fast as having it in the PBD. Otherwise the PSR file
>>> is refreshed prior to linking the dataobject to the PSR
>>> file. So I'm saving not only the datawindow creation
>>> overhead but the time to select and download it from
>>> the database too.
>>>
>>> You are right, PSR seems to go away with PB 12
>>> like some other techniques we've used in the past.
>>> What can I say? PB 12 is announced for Q1 2010
>>> (or is it H1 2010 meanwhile?). I'm not in a hurry
>>> to use a new PB version once it is released. So I
>>> conjecture if I'll be contrained to use PB 12 sometime
>>> computers will be so fast that the creation overhead
>>> is acceptable.
>>>
>>> Best regards
>>>
>>> Chris Werner
>>> f+s software gmbh
>>


Chris Werner Posted on 2009-03-10 15:43:14.0Z
From: "Chris Werner" <cwAT{PleaseNoSpam}f-s.de>
Newsgroups: sybase.public.commercial-isv.general
References: <49b67930$1@forums-1-dub> <49b6852c$1@forums-1-dub>
Subject: Re: dynamic datawindow reports
Lines: 184
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <49b68a92$1@forums-1-dub>
Date: 10 Mar 2009 07:43:14 -0800
X-Trace: forums-1-dub 1236699794 10.22.241.152 (10 Mar 2009 07:43:14 -0800)
X-Original-Trace: 10 Mar 2009 07:43:14 -0800, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.commercial-isv.general:276
Article PK: 103994

Hi Randy,

that's an interesting question but less a question of *how*. To do
it is as easy (or difficult) as doing it in PowerBuilder. Notice
for dynamic datawindows there isn't any "original" dataobject in a
PBL as part of the client application. The whole framework is metadata
driven (but gives the option to "plug in" hard coded PowerBuilder objects
to implement advanced functionality).
Part of the framework is some kind of "designer" (of course also
based on the framework itself). The consultant who is setting
up the system composes the structure (xplorers containing classes
containing views;classes are connected by relations; classes are sensible
for optional parameters [which may arise in dynamic selection
forms designed at runtime using InfoMaker]; classes generate
actual parameter values which flow along the relations and control
the selection of other class view reports). Once she has designed
some (or all) classes, views and relations to start with she navigates in
the client application into a view which initially contains no report. She
designs the report for the view using InfoMaker, navigates along the
relations to design other view reports. All the time she works in the
client application and see the results of her work like a privelegded
end user will see it later (a less privelegded end user will see only a
subset).

It is indeed a question of cost estimation and a decision who'll do
the changes when the model changes (customers IT department,
consultants, personnel of our company). Small schema changes
are easy to handle: You just have to know which reports are affected,
navigate there and change it. Even if the report is broken because of
schema changes you are "in" the view and can open the report in
InfoMaker.
Major changes cause more effort until the decision to either change
the reports or design them from scratch - as it would be in PowerBuilder.
Of course the whole metadata may affected - again like a whole
PowerBuilder application.
That's indeed a job for someone who knows all the basics about the
system and normally done by the originator of the system.
Because all that metadata stuff and datawindow syntax is in a handfull
of tables one can copy that between different databases. Of course it
needs a little bit of communication to prevent the end users from playing
around while major changes are undergoing.
One may it see as increase of complexity to have to maintain both an
application (and yes, we need to implement a lot of functionality beneath
the framework) AND a lot of metadata but this is easy payd off by a
boost of productivity.

Best regards

Chris Werner
f+s software gmbh


"Randy" <CGreenwellAtsparusaDotcom> schrieb im Newsbeitrag
news:49b6852c$1@forums-1-dub...

> Chris,
>
> How do you handle major changes to DWs when you upgrade the client. For
> example, table changes. What happens to all of the DWs the customer
> changed and they need to be updated with new columns or old columns are
> deleted?
>
> Curious...
>
> Randy
>
>
>
> M. Searer wrote:
>> thread restarted from the powerscript forum... last post from...Chris
>> Werner
>>
>>>>> computers will be so fast that the creation overhead is acceptable.
>>> Is this not the case now? I would have guessed that with dynamic
>>> creation of the datawindows syntax stored in a database that it would be
>>> fast enough.
>>
>> You may be right about that. When I was implementing the framework
>> that wasn't the case but yeah ... meanwhile. Have never checked that
>> because it is comfortable to write dw_1.dataObject = ls_tmplFileName
>> instead of fileOpen() ... fileRead(..., ls_sntx) ... fileClose() ...
>> dw_1.create(ls_sntx)
>> and checking the result and coding error messages. Okay, that would be
>> only one method which is called then instead of the dataObject assertion.
>> I'm looking forward to check and implement that some month after PB12
>> is released.
>>
>>> Are you doing this only for reports, or for data entry entry screens
>>> too?
>>
>> When I was designing the framework I thougt about reports only but
>> since then many things changed and I use that for simple single table
>> update screens too. At the time being I'm in process to extend it for
>> simple types of multi table updates (in the loaded data must be a one
>> to one relation between the updateable tables). But that's kinda expert
>> modus. ;-)
>>
>>> I update (and allow users to update via infomaker) reports via a .pbl
>>> since datawindows don't need to be compiled.
>>> This requires the whole pbl to get copied which I do at start up.
>>
>> Yes, that's a good solution too. To be honest (customers please stop
>> reading here) one reason to go along the way I choosed was to show
>> the magic how an application changes while I'm on the help desk
>> phone and the customer asks for a change of a report he is seeing
>> right in this moment. It is really enjoyable on both sides of the phone
>> line when I say "Click refresh and look if the new design is what you're
>> after". Another feature is that Infomaker is integrated in our framework
>> so when you are looking at a screen and want to change it, you do
>> that with one click on the context menu, find yourself in Infomakers
>> report painter having loaded the report. Change it, save it, see it.
>> Release
>> it - all users see it from now on. But my favorite feature is PB catalog
>> integration: After changing a report the appropriate properties of all
>> columns are parsed and written back to the PB catalog tables. When you
>> use this columns in another report its properties (column header, font
>> settings and so on) are already set for you. Okay, even if I'd really
>> like
>> to continue this I'm going to think about how to withstand the actual
>> economic situation. But that's no discussion for this forum.
>>
>> Best regards
>>
>> Chris
>>
>>
>>
>> "M. Searer" <nospam@nospam.com> schrieb im Newsbeitrag
>> news:49b55e18$1@forums-1-dub...
>>>>> computers will be so fast that the creation overhead is acceptable.
>>> Is this not the case now? I would have guessed that with dynamic
>>> creation of the datawindows syntax stored in a database that it would be
>>> fast enough.
>>>
>>> Are you doing this only for reports, or for data entry entry screens
>>> too?
>>>
>>> I update (and allow users to update via infomaker) reports via a .pbl
>>> since datawindows don't need to be compiled.
>>> This requires the whole pbl to get copied which I do at start up.
>>>
>>> regards,
>>> mike
>>>
>>>
>>> "Chris Werner" <cwAT{PleaseNoSpam}f-s.de> wrote in message
>>> news:49b4f942$1@forums-1-dub...
>>>> Actually I cache only the syntax, not the data. But this
>>>> is only because the data caching isn't used yet by the
>>>> users. If the report would contain data, that would also
>>>> be cached. On the other side I believe if the caching
>>>> would widely be used for data too I'd to change the
>>>> framework because data changes much more often
>>>> then syntax.
>>>>
>>>> The reason for caching is (indeed) UI performance.
>>>> When the user chooses a certain view (and she does
>>>> that all the time because our user interface framework
>>>> is based on this technique almost completely) a simple
>>>> check against the database determines if the syntax in
>>>> the database is newer than that one in the PSR file.
>>>> If it isn't (and this is the mostly the case) the dataobject
>>>> is linked to the PSR file on the local disk which is as
>>>> fast as having it in the PBD. Otherwise the PSR file
>>>> is refreshed prior to linking the dataobject to the PSR
>>>> file. So I'm saving not only the datawindow creation
>>>> overhead but the time to select and download it from
>>>> the database too.
>>>>
>>>> You are right, PSR seems to go away with PB 12
>>>> like some other techniques we've used in the past.
>>>> What can I say? PB 12 is announced for Q1 2010
>>>> (or is it H1 2010 meanwhile?). I'm not in a hurry
>>>> to use a new PB version once it is released. So I
>>>> conjecture if I'll be contrained to use PB 12 sometime
>>>> computers will be so fast that the creation overhead
>>>> is acceptable.
>>>>
>>>> Best regards
>>>>
>>>> Chris Werner
>>>> f+s software gmbh
>>>