We have run into unhandled exceptions with BO 5.0.x too. We finally narrowed one problem down to this sequence of events: 1. Open a report. 2. Close that report. 3. Try to open a report that uses a different universe - Crash.
If you leave Report 1 open, then you can open Report 2 with no problem, which argues against a need for more memory or more power. We have a case open with BusObj tech support, but as yet have no resolution (and it’s been some time).
We also had crashes while refreshing reports, but haven’t been able to reproduce that yet.
This all came up during testing of our upgrade from BO 4.1.3 to BO 5.0.x (which is now “on hold” because of these problems). We didn’t experience these problems in BO 4.1.3. The universes and the reports were not changed. The universes involved are both linked to another (3rd) universe. Repository and data are on Oracle. We run under Windows95.
We have recently upgraded several users to 5.0.1. They report having multiple instances each day of crashing with ‘exception access violation’ errors. These users typically have two copies of business objects running at once as well as other open applications such as Lotus Notes, Excel, Word. This problem did not occur on 4.1.2 which is what these users had been on. These users also report that all of their apps are running slower when B.O. 5.0.1 is running than they did with 4.1.2.
Has anyone experienced crashes or poor performance on upgrading? Our users have either 64mg or 128mg and are running under NT. The repository is on Oracle while our data is on DB2. I am wondering whether this could just be a situation where a more powerful machine is needed.
We have had problems refreshing reports in version 5.0.2. It seemed to occur when a new version of the universes was on the repository. It helps therefore to refresh (import) the universe explicitely (menu Tools / Universes …).
We also noticed that refreshing the universe occasionally produced an unhandled exception. By deleting the universe file from the directory “Universes”, we were able to successfully re-import the universe.
Good luck
Chris
We have run into unhandled exceptions with BO 5.0.x too. We finally narrowed one problem down to this sequence of events: 1. Open a report. 2. Close that report. 3. Try to open a report that uses a different universe - Crash.
If you leave Report 1 open, then you can open Report 2 with no problem, which argues against a need for more memory or more power. We have a case open with BusObj tech support, but as yet have no resolution (and it’s been some time).
We also had crashes while refreshing reports, but haven’t been able to reproduce that yet.
This all came up during testing of our upgrade from BO 4.1.3 to BO 5.0.x (which is now “on hold” because of these problems). We didn’t experience these problems in BO 4.1.3. The universes and the reports were not changed. The universes involved are both linked to another (3rd) universe. Repository and data are on Oracle. We run under Windows95.
We have recently upgraded several users to 5.0.1. They report having multiple instances each day of crashing with ‘exception access violation’ errors. These users typically have two copies of business objects running at once as well as other open applications such as Lotus Notes, Excel, Word. This problem did not occur on 4.1.2 which is what these users had been on. These users also report that all of their apps are running slower when B.O. 5.0.1 is running than they did with 4.1.2.
Has anyone experienced crashes or poor performance on upgrading? Our users have either 64mg or 128mg and are running under NT. The repository is on Oracle while our data is on DB2. I am wondering whether this could just be a situation where a more powerful machine is needed.
I found the same thing, it seems to be a function of the partial import. If there is not a lot of changes in the universe, it attempts to do this - I found it to be easier to delete beforehand.
Brent
We have had problems refreshing reports in version 5.0.2. It seemed to occur when a new version of the universes was on the repository. It helps therefore to refresh (import) the universe explicitely (menu Tools / Universes …).
We also noticed that refreshing the universe occasionally produced an unhandled exception. By deleting the universe file from the directory “Universes”, we were able to successfully re-import the universe.
Good luck
Chris
We have run into unhandled exceptions with BO 5.0.x too. We finally narrowed one problem down to this sequence of events: 1. Open a report. 2. Close that report. 3. Try to open a report
that uses a
different universe - Crash.
If you leave Report 1 open, then you can open Report 2 with no
problem, which
argues against a need for more memory or more power. We have a case open with BusObj tech support, but as yet have no
resolution (and
it’s been some time).
We also had crashes while refreshing reports, but haven’t been able
to reproduce
that yet.
This all came up during testing of our upgrade from BO 4.1.3 to BO
5.0.x (which
is now “on hold” because of these problems). We didn’t experience these problems in BO 4.1.3. The universes and
the reports
were not changed. The universes involved are both linked to
another (3rd)
universe. Repository and data are on Oracle. We run under
Windows95.
We have recently upgraded several users to 5.0.1. They report having multiple instances each day of crashing with ‘exception
access
violation’ errors. These users typically have two copies of business objects running at once as well as other open applications
such as
Lotus Notes, Excel, Word. This problem did not occur on 4.1.2 which is what these users had been on. These users also
report that
all of their apps are running slower when B.O. 5.0.1 is running
than
they did with 4.1.2.
Has anyone experienced crashes or poor performance on upgrading?
Our
users have either 64mg or 128mg and are running under NT. The
repository
is on Oracle while our data is on DB2. I am wondering whether this
could
just be a situation where a more powerful machine is needed.
It has been suggested by BO that when a Universe change is implemented that it should be exported to the repository twice to force a full import instead of an incremental import (which happens when the repository version number is 1 greater than the existing desktop version). There appears to be a problem with incremental imports. We have not tried this solution yet.