Continued Report Problems in 8099

[mikeallenbrown]

Thanks. We're on 8099.

And the report server was reenabled.

[Pizzadude]

I have spent several hour trying, without success, to solve this by editing reports, creating new reports, etc. Reports are failing to render about the bottom 20% of the page. The only cure is to run the WAS without using Always UP.

I have tried the latest nightly build. No change.

[mikeallenbrown]

This looks promising in my brief testing today...

I sent a video to Alpha demonstrating how reports in the developer don't render the same as they do on the app server. Alpha's response...

Hi Mike,

This is caused by the reference driver changes - we use the Display driver by default, This is more performant than using a printer driver (Which has been demonstrated to slow down over time, especially if rendering really large reports).
Unfortunately, using this driver can impact precision of text layout in PDFs.

This build supports changing the reference driver back if you run into this issue, this reverts to the using a PRINT driver (like it did before), This greatly increases the precision, and if you are not in the habit of printing 400 page pdfs, you should probably be fine on the performance side of things.

Here is the troubleshooting page that has been added to describe this issue & how to address it.

https://documentation.alphasoftware....%20Objects.xml

Thanks,
Cian Chambliss

I installed today nightly build, 8128, and set this property in the IDE and republished.

Ashampoo_Snap_Friday, April 8, 2022_19h47m26s.png

[Pizzadude]

This looks like it describes the symptoms I have been experiencing. I am traveling for a few days, but I will test as soon as I get back. Interesting that you received a response from Alpha, while they decided not to look into the bug report I sent.

[Pizzadude]

This is using the "Printer" option:

PrintSample.png

[Pizzadude]

At this point I have spent about 30 hours on this because it has been preventing me from updating to a new version of Alpha. I have been stuck on 7902 and there are features in newer builds that I want to use.
So I have been experimenting with nightly builds.
In nightly build 8134 Alpha has changed the PDF Reference Device. This is what it looks like now:

Untitled.png

And it seems to work correctly now. I was having spacing problems in RTF objects in reports in Stable build 8099.
In nightly build 8134, selecting "DISPLAY" causes the space preceding an inserted variable to not render. Text that should render as My Company Name, would be MyCompany Name, where Company Name is the inserted variable.
When "PRINTER" is selected the spacing is correct.

However in nightly build 8134 I found that printing an HTML report to a div fails to populate the div. Hopefully this will be fixed in the next stable build.

Also, running the WAS with Always UP no longer creates problems with reports in nightly build 8134.

[peteconway]

What a mess.

[Rich Hartnett]

I was wondering why my reports were having sentences cut off any place where I had used the 8pt Arial font since upgrading to 8099. Making it bigger or smaller solved the problem, but since I have about 100 reports using that size font universally, changing the font size is not acceptable. Even stranger is that I don't see the Reference Device Driver shown in the "cure" above.

Screen Shot 04-20-22 at 03.28 PM.jpg

[Pizzadude]

It is not in 8099. It is in subsequent Nightly Builds. Of course, nightly builds are not intended be used in a production application, because they are very likely to have additional bugs. So we must wait for an official Stable Build to be available and hope it is usable. This has always been a problem, and Alpha no longer releases "hot fixes" to official stable builds.

[nlk10010]

I recently experienced loads of problems with 8099 so I downgraded to 7295 (both Developer version and AAS version). My client calls up and says a particular report is "all running together". What does that mean??? I took a look and the formatting is a disaster, fields literally running into each other, no headers, etc. Not until I downgraded to 6699 did this disappear. BTW, I did all my testing on a local machine with separate AAS versions running, no Always Up. So now I'm stuck on 6699 and lost some features (e.g. Custom Excel Export) because to nudge the version up makes the app go haywire. Whose fault? Depends on how you define "fault": My code runs fine in 6699 so it's Alpha's fault. I'm sure Alpha will say I'm doing something "wrong" in my app which newer builds now penalize. Of course there seem to be posters in this thread who are OK with Builds later than 6699, but I've tried 7295 and 7902 and neither works.

You know, when I first upgraded to 8099 my client called me saying the mobile app that had been running fine under AAS 6699 (Developer Version 7295) is now freezing and causing all sorts of issues on drivers' mobile devices. So I thought it might be ZH, and they asked if I had seen the posts about issues with 8099. I said that I had despaired of ever getting anything positive with AAS "stability problems" out of the forums, not because the people here are anything less than knowledgeable and stellar, but because this type of problem is usually beyond the ability of users to solve. Alpha will demand a "test case" and deny any responsibility unless/until you can provide one, which in real world situations can be virtually impossible. So I keep stepping back my versions until I hit one that seems to work.

[Pizzadude]

If I try to view the latest post to this thread by nlk10010 at https://forum.alphasoftware.com/node/936838 I get "Sorry, you are not authorized to view this page. For assistance contact the site administrator."
Never seen that before.

[mikeallenbrown]

Sounds like the post was either moved or deleted.

[Ted Giles]

Works for me. On my Tablet.
I had these sort of issues until Lenny got involved on my DT.
Take a look at the thread about the problem on the Forum Use page, Joe

[Steve Wood]

I found a similar problem in build 8099 where Advanced export to Excel "did nothing". My problem has been fixed in the latest nightly build, build signed zero problem

[CharlesParker]

FINALLY WENT FROM 7295 TO 8099 WITHOUT ERROR!

Personally I also had problems with 8099 and was forced to go back to 7295 myself - nothing after 7295 would work without causing some sort of errors in my application. I have been using AS for about 6 years now, I like the Universal installer and have been using it to keep trying to get 8099 to work with my application that was running perfectly for me under 7295 so in trying to work it out with Selwyn over the last few days and as per my usual experience he couldn't duplicate my supposed bugs. He looked at my server and noticed I was not using the default paths and that it was documented that they were changed quite some time ago. I realized that my default folder for my server was a5v12 and not the default path used by the installer. I kept having to pick that folder when upgrading and downgrading server versions. I had also installed the community edition and the IIS server as well - all of course in their own folders - my dev machine here at home had about 4 different installs as well. But hey it was working fine...I just couldn't move beyond 7295

I decided to do some clean-up and deleted the folders where the server and the dev was installed - I mean if things went sideways I could just go to the recycle bin and restore them so why not...

Believe it or not, once i had the installs in the default paths and of course they were clean installs - without making any changes to my components they starting working as expected - probably why Selwyn saw no issues.
I did have to go in and edit a few curl files that were referencing the old path, and one other thing on the server (at ZebraHost) I had to run the server application once to get windows to allow it through the firewall. Next up I had to edit my shortcuts that run via always up with custom configs and now the 8099 version is running without error.

This has baffled me for quite some time, I am not sure what the install paths have to do with the plethora of errors I would get when trying to go from 7295 to 8099 but I am glad I got it worked out.
Now, the Universal Installer correctly shows my installed software in the default paths and this makes it much easier to use.
So my advice if you've been using AS for awhile and cannot get beyond a certain version - check out your environment - get rid of the unnecessary installs and run a clean install.

worked for me!