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.

DDDW Refresher Help

4 posts in DataWindow Last posting was on 2008-06-18 17:26:41.0Z
Jeff Gibson Posted on 2008-06-17 22:48:51.0Z
Reply-To: "Jeff Gibson" <jgibson@interceptsolutions.com>
From: "Jeff Gibson" <jgibson@interceptsolutions.com>
Newsgroups: sybase.public.powerbuilder.datawindow
Subject: DDDW Refresher Help
Lines: 51
Organization: Intercept Solutions
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48583f53$1@forums-1-dub>
Date: 17 Jun 2008 15:48:51 -0700
X-Trace: forums-1-dub 1213742931 10.22.241.152 (17 Jun 2008 15:48:51 -0700)
X-Original-Trace: 17 Jun 2008 15:48:51 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.powerbuilder.datawindow:87206
Article PK: 416463

I have recently run into an issue with dddw's that I had never seen before.
This happens in PB7 and it happens in latest build of 10.2.1, so that's my
benchmark. For my example, lets say I have a customer datawindow that has a
mailing, shipping and billing address on it. Each address has a state dddw.
I have handles set to each of these dddw's.

mailing_state, shipping_state and billing_state, are all fk's to the states
table from the customers table. Data value in the dddw is set to the pk of
the states table. Lets say that all three state values are set to CA
(California). The data value from the states table is 5. It is the fifth
row in each of the dddw's.

Now lets say that I retrieve the main customers datawindow. Everything
retrieves as it should, and each state shows up as CA.

Now, before I start to interact with the main datawindow, I press a command
button that does a getrow() against each of the dddw handles I have. Let's
just say I jam the return values into a messagebox.

When I press the command button, it tells me that the currentrow in each
dddw is 1. (even though its really 5). No matter what, if I haven't
interacted with the dddw columns, it spits back a 1 for the currentrow for
that column.

Now, Let's say I tab through each of the dddw's. I don't even interact with
the data value. I just tab through each dddw. When I press the command
button to tell me the current row that each dddw is on, they all spit back 5
now. I could even trigger a setcolumn against each dddw and then put focus
back on the window. That also will make the dddw's return a 5 instead of a
1.

Has this always been normal behavior for a dddw and I've just never noticed
it? Seems kind of odd that it would tell me that each dddw had its current
row set to 1, but by tabbing through the dddw's, doing a setcolumn, or even
just clicking the dddw (but not changing the value), the dddw's start
telling me what the correct row is.

I guess I'm just wondering if this is normal behavior for the dddw. I have
some issues I'm running into with some generic update code I wrote, and it's
pulling back the wrong row from the dddw if I haven't interacted with the
column.

Any info on this would be greatly appreciated.

TIA.

Jeff Gibson
Intercept Solutions - Sybase SQL Anywhere OEM Partner
Nashville, TN


Philip Salgannik Posted on 2008-06-18 15:04:04.0Z
Reply-To: "Philip Salgannik" <PhilipSalgannik@work.com>
From: "Philip Salgannik" <PhilipSalgannik@work.com>
Newsgroups: sybase.public.powerbuilder.datawindow
References: <48583f53$1@forums-1-dub>
Subject: Re: DDDW Refresher Help
Lines: 60
Organization: ATWORK
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <485923e4$1@forums-1-dub>
Date: 18 Jun 2008 08:04:04 -0700
X-Trace: forums-1-dub 1213801444 10.22.241.152 (18 Jun 2008 08:04:04 -0700)
X-Original-Trace: 18 Jun 2008 08:04:04 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.powerbuilder.datawindow:87208
Article PK: 416465

Are these columns set to be allowedit?
Anyway, there is no direct connection between the current row in the dddw
and the ability of the main datawindow to display the right decode. The
concept of current row is relevant ONLY when you interact with the dddw. As
somebody already pointed out in response to your previous post on this
subject, you can't rely on the getrow, you need to find(...) the right row

"Jeff Gibson" <jgibson@interceptsolutions.com> wrote in message
news:48583f53$1@forums-1-dub...
>I have recently run into an issue with dddw's that I had never seen before.
>This happens in PB7 and it happens in latest build of 10.2.1, so that's my
>benchmark. For my example, lets say I have a customer datawindow that has
>a mailing, shipping and billing address on it. Each address has a state
>dddw. I have handles set to each of these dddw's.
>
> mailing_state, shipping_state and billing_state, are all fk's to the
> states table from the customers table. Data value in the dddw is set to
> the pk of the states table. Lets say that all three state values are set
> to CA (California). The data value from the states table is 5. It is the
> fifth row in each of the dddw's.
>
> Now lets say that I retrieve the main customers datawindow. Everything
> retrieves as it should, and each state shows up as CA.
>
> Now, before I start to interact with the main datawindow, I press a
> command button that does a getrow() against each of the dddw handles I
> have. Let's just say I jam the return values into a messagebox.
>
> When I press the command button, it tells me that the currentrow in each
> dddw is 1. (even though its really 5). No matter what, if I haven't
> interacted with the dddw columns, it spits back a 1 for the currentrow for
> that column.
>
> Now, Let's say I tab through each of the dddw's. I don't even interact
> with the data value. I just tab through each dddw. When I press the
> command button to tell me the current row that each dddw is on, they all
> spit back 5 now. I could even trigger a setcolumn against each dddw and
> then put focus back on the window. That also will make the dddw's return
> a 5 instead of a 1.
>
> Has this always been normal behavior for a dddw and I've just never
> noticed it? Seems kind of odd that it would tell me that each dddw had
> its current row set to 1, but by tabbing through the dddw's, doing a
> setcolumn, or even just clicking the dddw (but not changing the value),
> the dddw's start telling me what the correct row is.
>
> I guess I'm just wondering if this is normal behavior for the dddw. I
> have some issues I'm running into with some generic update code I wrote,
> and it's pulling back the wrong row from the dddw if I haven't interacted
> with the column.
>
> Any info on this would be greatly appreciated.
>
> TIA.
>
> Jeff Gibson
> Intercept Solutions - Sybase SQL Anywhere OEM Partner
> Nashville, TN
>


Jeff Gibson Posted on 2008-06-18 15:51:24.0Z
Reply-To: "Jeff Gibson" <jgibson@interceptsolutions.com>
From: "Jeff Gibson" <jgibson@interceptsolutions.com>
Newsgroups: sybase.public.powerbuilder.datawindow
References: <48583f53$1@forums-1-dub> <485923e4$1@forums-1-dub>
Subject: Re: DDDW Refresher Help
Lines: 82
Organization: Intercept Solutions
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48592efc$1@forums-1-dub>
Date: 18 Jun 2008 08:51:24 -0700
X-Trace: forums-1-dub 1213804284 10.22.241.152 (18 Jun 2008 08:51:24 -0700)
X-Original-Trace: 18 Jun 2008 08:51:24 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.powerbuilder.datawindow:87209
Article PK: 416467

Hey Philip,

Actually, the difference here between my last post and this one is that
allowedit was on with the first example. Allowedit is not turned on for
this example.

The dddw consists of the state code as the display column, and the pk from
the state table in the data column.

Amazing that if you just touch the column by tabbing through it, or via
code, the getrow() will return the correct row. But up until that point
after the initial retrieve, they all return row 1. Would you think it would
probably be safe to say that this is by design and has always been the way
the datawindow has worked?

Thanks for the response.

Jeff Gibson
Intercept Solutions - Sybase SQL Anywhere OEM Partner
Nashville, TN

"Philip Salgannik" <PhilipSalgannik@work.com> wrote in message
news:485923e4$1@forums-1-dub...
> Are these columns set to be allowedit?
> Anyway, there is no direct connection between the current row in the dddw
> and the ability of the main datawindow to display the right decode. The
> concept of current row is relevant ONLY when you interact with the dddw.
> As somebody already pointed out in response to your previous post on this
> subject, you can't rely on the getrow, you need to find(...) the right row
> "Jeff Gibson" <jgibson@interceptsolutions.com> wrote in message
> news:48583f53$1@forums-1-dub...
>>I have recently run into an issue with dddw's that I had never seen
>>before. This happens in PB7 and it happens in latest build of 10.2.1, so
>>that's my benchmark. For my example, lets say I have a customer
>>datawindow that has a mailing, shipping and billing address on it. Each
>>address has a state dddw. I have handles set to each of these dddw's.
>>
>> mailing_state, shipping_state and billing_state, are all fk's to the
>> states table from the customers table. Data value in the dddw is set to
>> the pk of the states table. Lets say that all three state values are set
>> to CA (California). The data value from the states table is 5. It is
>> the fifth row in each of the dddw's.
>>
>> Now lets say that I retrieve the main customers datawindow. Everything
>> retrieves as it should, and each state shows up as CA.
>>
>> Now, before I start to interact with the main datawindow, I press a
>> command button that does a getrow() against each of the dddw handles I
>> have. Let's just say I jam the return values into a messagebox.
>>
>> When I press the command button, it tells me that the currentrow in each
>> dddw is 1. (even though its really 5). No matter what, if I haven't
>> interacted with the dddw columns, it spits back a 1 for the currentrow
>> for that column.
>>
>> Now, Let's say I tab through each of the dddw's. I don't even interact
>> with the data value. I just tab through each dddw. When I press the
>> command button to tell me the current row that each dddw is on, they all
>> spit back 5 now. I could even trigger a setcolumn against each dddw and
>> then put focus back on the window. That also will make the dddw's return
>> a 5 instead of a 1.
>>
>> Has this always been normal behavior for a dddw and I've just never
>> noticed it? Seems kind of odd that it would tell me that each dddw had
>> its current row set to 1, but by tabbing through the dddw's, doing a
>> setcolumn, or even just clicking the dddw (but not changing the value),
>> the dddw's start telling me what the correct row is.
>>
>> I guess I'm just wondering if this is normal behavior for the dddw. I
>> have some issues I'm running into with some generic update code I wrote,
>> and it's pulling back the wrong row from the dddw if I haven't interacted
>> with the column.
>>
>> Any info on this would be greatly appreciated.
>>
>> TIA.
>>
>> Jeff Gibson
>> Intercept Solutions - Sybase SQL Anywhere OEM Partner
>> Nashville, TN


Philip Salgannik Posted on 2008-06-18 17:26:41.0Z
Reply-To: "Philip Salgannik" <PhilipSalgannik@work.com>
From: "Philip Salgannik" <PhilipSalgannik@work.com>
Newsgroups: sybase.public.powerbuilder.datawindow
References: <48583f53$1@forums-1-dub> <485923e4$1@forums-1-dub> <48592efc$1@forums-1-dub>
Subject: Re: DDDW Refresher Help
Lines: 88
Organization: ATWORK
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <48594551$1@forums-1-dub>
Date: 18 Jun 2008 10:26:41 -0700
X-Trace: forums-1-dub 1213810001 10.22.241.152 (18 Jun 2008 10:26:41 -0700)
X-Original-Trace: 18 Jun 2008 10:26:41 -0700, vip152.sybase.com
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.powerbuilder.datawindow:87210
Article PK: 416466

I am pretty sure it was always like that.

"Jeff Gibson" <jgibson@interceptsolutions.com> wrote in message
news:48592efc$1@forums-1-dub...
> Hey Philip,
>
> Actually, the difference here between my last post and this one is that
> allowedit was on with the first example. Allowedit is not turned on for
> this example.
>
> The dddw consists of the state code as the display column, and the pk from
> the state table in the data column.
>
> Amazing that if you just touch the column by tabbing through it, or via
> code, the getrow() will return the correct row. But up until that point
> after the initial retrieve, they all return row 1. Would you think it
> would probably be safe to say that this is by design and has always been
> the way the datawindow has worked?
>
> Thanks for the response.
>
> Jeff Gibson
> Intercept Solutions - Sybase SQL Anywhere OEM Partner
> Nashville, TN
>
> "Philip Salgannik" <PhilipSalgannik@work.com> wrote in message
> news:485923e4$1@forums-1-dub...
>> Are these columns set to be allowedit?
>> Anyway, there is no direct connection between the current row in the dddw
>> and the ability of the main datawindow to display the right decode. The
>> concept of current row is relevant ONLY when you interact with the dddw.
>> As somebody already pointed out in response to your previous post on this
>> subject, you can't rely on the getrow, you need to find(...) the right
>> row
>> "Jeff Gibson" <jgibson@interceptsolutions.com> wrote in message
>> news:48583f53$1@forums-1-dub...
>>>I have recently run into an issue with dddw's that I had never seen
>>>before. This happens in PB7 and it happens in latest build of 10.2.1, so
>>>that's my benchmark. For my example, lets say I have a customer
>>>datawindow that has a mailing, shipping and billing address on it. Each
>>>address has a state dddw. I have handles set to each of these dddw's.
>>>
>>> mailing_state, shipping_state and billing_state, are all fk's to the
>>> states table from the customers table. Data value in the dddw is set to
>>> the pk of the states table. Lets say that all three state values are
>>> set to CA (California). The data value from the states table is 5. It
>>> is the fifth row in each of the dddw's.
>>>
>>> Now lets say that I retrieve the main customers datawindow. Everything
>>> retrieves as it should, and each state shows up as CA.
>>>
>>> Now, before I start to interact with the main datawindow, I press a
>>> command button that does a getrow() against each of the dddw handles I
>>> have. Let's just say I jam the return values into a messagebox.
>>>
>>> When I press the command button, it tells me that the currentrow in each
>>> dddw is 1. (even though its really 5). No matter what, if I haven't
>>> interacted with the dddw columns, it spits back a 1 for the currentrow
>>> for that column.
>>>
>>> Now, Let's say I tab through each of the dddw's. I don't even interact
>>> with the data value. I just tab through each dddw. When I press the
>>> command button to tell me the current row that each dddw is on, they all
>>> spit back 5 now. I could even trigger a setcolumn against each dddw and
>>> then put focus back on the window. That also will make the dddw's
>>> return a 5 instead of a 1.
>>>
>>> Has this always been normal behavior for a dddw and I've just never
>>> noticed it? Seems kind of odd that it would tell me that each dddw had
>>> its current row set to 1, but by tabbing through the dddw's, doing a
>>> setcolumn, or even just clicking the dddw (but not changing the value),
>>> the dddw's start telling me what the correct row is.
>>>
>>> I guess I'm just wondering if this is normal behavior for the dddw. I
>>> have some issues I'm running into with some generic update code I wrote,
>>> and it's pulling back the wrong row from the dddw if I haven't
>>> interacted with the column.
>>>
>>> Any info on this would be greatly appreciated.
>>>
>>> TIA.
>>>
>>> Jeff Gibson
>>> Intercept Solutions - Sybase SQL Anywhere OEM Partner
>>> Nashville, TN
>
>