PH710G

[alex ling]

---Chris Sharman <Chris.Sharman@ccagroup.co.uk> wrote:
>
> >Anyone out there has upgraded to 710G on OpenVMS/InterBase? We at
> >Republic Mase Australia are experiencing a few problems -
> 
> I'm using OpenVMS Alpha 7.1, PH 7.10G with RMS.
> 
> >1. Linking a LONG BINARY to a SHORT BINARY in QTP and QUIZ gave Data
> >Conversion Error and crashed.
> >- Workaround: link LONG to LONG only.
> 
> Don't know this one (done very little Quiz/QTP testing). Does it
have a bug
> number ? I'm not sure (without extensive checking) how much trouble
it's likely
> to give us here. Do other types (ie zoned > binary, binary > zoned)
work OK ?
> 


I am still waiting for the bug number from Support. They informed me
that Ottawa has accepted it as a problem. I need it fixed in the
coming RBF, ie 710G1. Without the fix the product is useless to us
because the problem is fundamental and its implication is extensive
for our application.

As with other numeric datatypes, I can't be sure. The problem seems to
centre around linking a numeric datatype to a non-matching numeric
datatype. In my case, the problem is linking a LONG BINARY (4-byte) to
a SHORT BINARY (2-byte). Both link-items are Interbase fields.

Below's case is also a problem -

REQUEST A
  etc
  DEFINE X NUM*6 = ITEM-X OF TABLE-X
  etc
  SUBFILE SS INCLUDE X, etc
REQUEST B
  ACCESS *SS LINK X TO ITEM-X OF TABLE-X
  etc

(where ITEM-X is a SHORT BINARY Interbase field)

I got Data Conversion Error in QTP on the LINK statement in REQUEST B
and it crashed. In my case, I have to work around it by changing
ITEM-X from SHORT to LONG BINARY in Interbase.

It does seem to me that it wants matching size for numeric datatypes
in linking?? Please correct me, anyone from Cognos? Note that the
program compiles okay but when you run it that's when it hits you. In
the beginning I was fooled by it that everything was fine because the
entire application recompiled without an error!!


> >2. FIELD <item> FOR X,Y where X >1 in QUICK gave Access Violation and
> >dropped to DCL.
> >- Workaround: aviod multiple-line. That's use X = 1.
> 
> I've seen this one (bugs 240195, 244198, fixed in 7.10.G1).
> 
> I've also found one with lookup on a, on b, on c, on d, on e, noton
primary
> screwing up the field type (should be char*8, treated as date). This
fails one
> of our critical screens.
> 

Thanks. Good that this one is out of the way.


> I don't think 710Fn offers you a lot of benefit over 710E4, other
than maybe
> some more bugfixes.
> 

I agree with you entirely on this. But Cognos put out a Y2K warranty
which is good for 710F2 and later versions only. We have to have a Y2K
compliant version.


> 7.10.G1 is in development, and fixes the first of these (so far),
and a few
> other things I believe. Now is the time to give 7.10G and your
support contract
> lots of exercise.
> 
> I've heard "at least 4-6 weeks" for 7.10G1 - it's currently still in
> development, so it's presumeably not too late to get serious bugs
fixed in it.
> I'm not sure if that's 4-6 weeks for shipping or for beta. 

I hope my problems (everyone else's too now) get to the developers in
time for G1. That's why I have been demanding a bug number from
Support. If they miss mine in G1, I don't have time left to wait
anymore.


> Can we have a 710G/G1 discussion with input of privileged
information from
> Cognos ?

Good idea.

 
Thanks,
A Ling.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.