we're uping to 77. Would anyone like to share an opinion as tothe most stable windows version(s), client and server? I remember last summit that two focwizards shared their opinions , and i'm wondering if there's a consensus today?
molto grazie...

This message has been edited. Last edited by: <Kathryn Henning>,

my vote is for v7.7.03.

I vote for 7.7.03.

why you are not going to 8 instead of 77? Is that because of the license fee?

We are going to 7.7.05, and seems OK so far, but its early days.

Great you are upgrading Susannah.

7.7.03 has been very stable.

7703 is stable, but it does lack the one feature that was critical to us as a non - M$ Office company, namely the EXL07 output.

This only appeared with 7704, but we had a lot of grief with that version in terms of the HTML composer (which was still 7703). Since moving to 7705 things appear to be much better from the HTML composer side of things with no issues on the server side.

Our reportcaster jobs are still mostly running on the 7704 server, but the ad hoc menu driven reports are running off of 7705 (I run two datamart rebuilds each night - one on each server).

thanks everyone.
i think we'll go 7705, now that both c & s are available in that version. bullet biting.

What's Firebird, George? i used to drive one, back when it was Pontiac. wooo...grey matter just exploded.

When we upgraded from v7.7.03 to v7.7.05 we had quite a few issues. Accordion reports beahving a little differently... and some other stuff I haven't had time to compile a list of. One of the biggest things was rounding seemed to have changed, which annoyed our users greatly - I don't have the details right now, but I can dig up the tech support case. We opened several cases to resolve issues upgrading.

I've also heard going from 7.7.05 to 8 is a pretty smooth process although we went from 7.7.03 to 8 and didn't encounter too many problems.

yikes . rounding issues? wicked problem

The issue is with the Oracle data adapter.

We have the following issue.

In 7705 there is an inconsistency in the handling of ORACLE NUMBER fields. In some cases truncation occurs, resulting in incorrect results in the reports.

The Source Data in Oracle is defined just as NUMBER (no precision, no scale).

This is what we get:

 
 Business Date   D20.2 D8       P20.2 P16      P20.6 P16
 2013/09/26      14.42          14.41          14.415000
 2013/09/26      80,733.71      80,733.71      80,733.715000

Why for the D20.2/D8 is the first value rounded "up", and the second rounded "down"?

-------------------

 The raw data is:
   COL1  COL2
 =====================
   'AA', 00080733.7150
   'BB', 00000014.4150
 
 I've confirmed via in-house testing (Sample Data on the synonym) that in 7703
 the results received are:
 
 COL1   COL2
 ========================
 AA     14.42
 BB     80733.72
 
 Whereas in all releases 7704 and up the results are:
 
 COL1   COL2
 ========================
 AA     80,733.71
 BB     14.42
 
 The customer complaint is that both values in the sample data should be
 rounded up because the 3rd less significant decimal is a "5" in both cases:
   x.415 => x.42
   x.715 => x.72
 
 That's what the product did before 7.7.04
 
 It is inconsistent that:
  -  x.415 becomes x.42
  -  while x.715 becomes x.71.
 
 The values in 7703 are the following:
 Raw data     USAGE=D20.2
 ---------    --------------
 14.415 =>    14.42
 80733.715 => 80733.72

-------------------

Currently, engineering is in the QA testing phase of these new rounding algorithms. It is our belief that they will produce results that are mathematically guaranteed to be correct.

However, as a by-product of that work, engineering provided this conclusion:

The only way to guarantee decimal accuracy is to use decimal arithmetic, this is accomplished by using a P format.

So the recommendation is to use a P format for any such columns that require decimal accuracy. As far as how the D formats will be rounded, we anticiapate having a fix that includes the new algorithms for 7706.

-------------------

Engineering asked that I point out that it is a common misconception that switching from D20.2CM to D20.4CM adds two extra digits of precision. In fact that only adds two extra digits to the display of what is presumably the same internal value.

In either case, if you wish to use the D format, 7706 gen 784 and higher will have the new algorithms which we have great confidence in. It is scheduled for release this quarter (Q1 2014).

holy cow. we'll wait. We're all Oracle here. god bless you Frankie Martini!
I've heard that going from 768 to 77n is a PDF formatting nightmare.
Any one have any thoughts on that?

quote:

What's Firebird, George? i used to drive one, back when it was Pontiac. wooo...grey matter just exploded.

Iconic and jealous.

In V7.6.11 the line spacing changed to cater for some latin characters overflowing onto the next line.

Report output takes more pages in 7.7 than 7.1

Other things we have found are:

• Line spacing has changes (As above), changed the top and bottom gaps
  
• Some reports sstarted paneling, had to adjust the left and right gaps
  
• DT(00000000000000000) no longer works
  
• BORDER=MEDIUM seems thicker, in EXL2K
  
• FIELD MISSING ON /format no longer works, swapped MISSING ON to after the format.
  
• A DECODE in a hard concatemation caused a FOC282
  

I'll leave the discussion of /P vs /D to Jack, Wep etc ....

Firebird is an open source database much like MySQL.

Our subsidiary company in Guatemala uses a sales/accounting/banking application made by a company called Aspel in Mexico. That application uses Firebird as the back end. Luckily there is an open-source JDBC driver for the database which makes it pretty easy to connect with WF.

It does throw one error about a text field when I run the test connection routine on the WF server, but actual data comes across very nicely. I've even used MODIFY to change values in the database, which is cool.

ah. we've found out some stuff.
the rounding issue:
D15.2 or lower is safe. (whew)
the problems start at 16 and bigger.
but it will be fixed with the new oracle adapter due out in the 7706 release end of april. and apparently server/client will all the the same from now on. whew.
Corollary: there was an issue with much bigger D numbers (too rich for me), and that is now fixed with a new compiler, independent of the oracle issue.
OK, now pdf, i understand what they did, but i don't know why they bothered. they made the cells taller, so that where there was a hyperlink, so you could see the underline. (who cares? really)
so there's a case on it. TM4711. the tech memo is titled 'PDF Remediation'...

This message has been edited. Last edited by: susannah,

quote:

but it will

always

quote:

be fixed with the new

...