Version too old error

Post Author: niketya
CA Forum: Older Products
I have never used Crystal Report so my knowledge about this product is rather poor. We are using crystal viewer in a custom made application which generates crystal reports and saves them in 1rd format. Granted we can export the documents to pdf, however people choose not to. Anyway, we are getting a new web application and it does not use Crystal Report. I have installed the CR XI viewer and when open a report file I get the following along the lines of "Version too old use version 9 to open it". Clearly the generated reports are from version 9. I was wandering If I could open these reports in Access or in a stand alone application? Many thanksNiketya

Actually the JRE/Jinit version has nothing to do with the error. The error is caused when the Forms applet (i.e. frmall.jar, frmall_jinit.jar) version is not in sync with the Forms Servlet or Runtime version.
Clear the JRE/Jinit JAR cache and retest. If this continues to fail, consider whether or not you have recently installed any patches to the Application Server. If so, you may have not successfully completed that task. If the client jar files (i.e. frmall.jar, frmall_jinit.jar) where not updated during a patch installation, the error you are seeing is likely to occur. This can also occur if the client accesses more than one minor version of an Application Server installation (i.e. 10.1.2.0.2 and 10.1.2.2).
Installing a new JRE only indirectly solves this problem. The reason is that when a new JRE is installed, the JRE cache is empty the first time it is used and therefore resembles the cache clearing recommendation noted above.
FYI: FRM-92150 Client version too new occurs, after a patch installation, when the client JAR files are updated but the Forms Servlet or Runtime is not. Again, clearing cache can sometimes solve this problem if recent patching was not attempted.

Similar Messages

Frm-92160 web version too old error

plz suggest the solution to overcome from it

Actually the JRE/Jinit version has nothing to do with the error. The error is caused when the Forms applet (i.e. frmall.jar, frmall_jinit.jar) version is not in sync with the Forms Servlet or Runtime version.
Clear the JRE/Jinit JAR cache and retest. If this continues to fail, consider whether or not you have recently installed any patches to the Application Server. If so, you may have not successfully completed that task. If the client jar files (i.e. frmall.jar, frmall_jinit.jar) where not updated during a patch installation, the error you are seeing is likely to occur. This can also occur if the client accesses more than one minor version of an Application Server installation (i.e. 10.1.2.0.2 and 10.1.2.2).
Installing a new JRE only indirectly solves this problem. The reason is that when a new JRE is installed, the JRE cache is empty the first time it is used and therefore resembles the cache clearing recommendation noted above.
FYI: FRM-92150 Client version too new occurs, after a patch installation, when the client JAR files are updated but the Forms Servlet or Runtime is not. Again, clearing cache can sometimes solve this problem if recent patching was not attempted.

FRM-92160 web version too old

Hi guys,
I had installed oracle 9i and developer6i on the server and configue IIS .When i access through client,if win 98 is installed on client it gives FRM-92160 web version too old error but on client where win2000 is installed ,it works.Any help??

Check if you have the correct version of Jinitiator on your Win 98 machine.

FRM-92160:Fatal error:Webclient version too old

Somebody pls assist.
I am running 11gR2 on Redhat, the forms can run on ie9 but can't on ie8. I am getting "FRM-92160:Fatal error:Webclient version too old". Anything I didn't do? I need this wotking as well on ie8.
Any help would be appreciated.
regards
Mo

Fortunately, the "Web client too old" or "Web client too new" errors are very accurate and clear. When a Forms application attempts to start, one of the first things which occurs is a verification that the client applet (frmall.jar) is of the same version as the server side runtime which is about to host it. "Web client too old", means that the client jar is of an older version than the server side runtime (i.e. frmweb.exe). This can occur if more than one Forms version has been accessed from the same server. Remember that the jar files are cached on the client (in the JRE). So, if you were to run something like v10 from serverA then attempt to run v11 from the same server, you likely would end up with a client too old error. The same would be true if you first try to run 11.1.1 then attempt to access 11.1.2 from the same machine. The issue can also occur if for some reason the jar files in the installation were not patched during a patch installation. This would be rare, but could occur if the patch installation failed during the process. It could also occur if you copies old files into the installation. This is never a good idea.
So, as mentioned, start by clearing the JRE cache and retesting.
1. Close ALL open browsers.
2. Open the JRE Control Panel (found on the Windows Control Panel).
3. On the General tab, click on "Settings..."
4. Then click on "Delete files..."
5. Then click on "Ok".
6. Exit the JRE Control Panel and retest.
Important to note is that JRE7 is NOT supported with 11.1.2.0. Be sure that you are using JRE6. If you have JRE7 installed, I would recommend closing ALL open browsers and uninstalling it. You should have only JRE6 installed before testing.

FRM-92160: Web Client version too old

Hi folks,
i have been developing and running my forms using Oracle 9iDS and the Oracle 9i database. The forms are run in the browser using the version of OC4J that comes with the developer suite.
i installed Oracle 10g Application server forms and reports services recently, however i have decided not to run my forms through the application server as yet.
when i tried to run running a form, i had an error message saying
FRM-92160: Web Client version too old.
I tried looking up the error but couldn't find it anywhere.
I can't run my forms now and i do not want to go through the application server as yet.
Any suggestions as to what to do?
Thanks in advance.

I run into the same problem after upgrading my AS10g/W2k to 904011: Forms from the MiddleTier did run, but a Forms started from the DevSuite-environment would raise FRM-92160.
What worked in my case was copying the MidTier's '...\forms90\java' files over to the DevSuite, ie.
- backup [DevSuite_Home]\forms90\java to java0
- copy [MidTier_Home]\forms90\java to [DevSuite_Home]
After that, my Forms run flawlessly from both DevSuite's OC4J and the AS MidTier. I also 'upgraded' formsweb.cfg in [DevSuite_Home] from JInit 1.3.1.17 to 1.3.1.18 - works.
Cheers
Tino

Snapshot too old error occured, kindly need solution for it...

Dar friends
I got snapshot too old error on most used database
Kindly give me the solution....
my solution was
Alter rollback segment <rollback segmnt name>
datafile '<path>/filename.dbf' resize <no>k;
or
alter rollback segment <rollback segmnt name>
add datafile '<path>/filename.dbf' size <no>k
storage(initial 1k nxt 1k minextnts 2 maxextents unlimited)
Kindly suggest me wheather my code is currect or not...
Ur
Friend

I don't know what version of the database you are running? I'm only using 8.1.7.4. But where I come from, you add datafiles to the tablespace, not the rollback segment.
alter tablespace rollback
add datafile '<blah, blah>'
size 147m
autoextend on next 100m maxsize 2047m;
Make sure that you have a suitable number of rollback segments that are well-sized extents. But mostly, listen the Tom Best, and try and introduce some best practices (no pun intended) to reduce the likelihood of this situation arising.

Advanced Queues Snapshot too old error

I am using the advanced queues to submit work for parallel processes running through the Oracle Job Queue.
I have attempted running anywhere from 1 to 5 simultaneous processes (in addition the the process which submits them to the Oracle job queue and populates the advanced queues) and I am getting sporadic Snapshot too old errors when the other processes are attempting to dequeue. The Advanced queues are populated before the other processes are submitted to the job queue, so I don't see that there could be conflicts between one process enqueuing while another is dequeuing.
The reason I am attempting this is to try and gain some performance by running processes in parallel.
Has anyone else had problems like this? Is this a bug in Oracle 8.1.6? Is there a parameter setting I need to adjust? Are there any suggestions for getting around this problem?

I don't know what version of the database you are running? I'm only using 8.1.7.4. But where I come from, you add datafiles to the tablespace, not the rollback segment.
alter tablespace rollback
add datafile '<blah, blah>'
size 147m
autoextend on next 100m maxsize 2047m;
Make sure that you have a suitable number of rollback segments that are well-sized extents. But mostly, listen the Tom Best, and try and introduce some best practices (no pun intended) to reduce the likelihood of this situation arising.

Snapshot too old error - disambiguation required.

[http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923]
It is known that Oracle provides row-level locks, meaning, two different transactions can update two different rows,
1. Is this true even if they reside in the same block?
2. If yes, as per the reasons stated in the above reference, Oracle should not find that the block has been modified for that particular, different, row. I am baffled at this point.
Resue needed.
Thanks in adv.
Aswani V.

if your concern is abou snapshoot too old (ora-01555) error, you know the reason for this undo tablespace size and the length of the longest running query. If you need to be able to get consistent read version of the block, which is needed for your long running query(which raises snapshot too old error), you have two options. 1) you can increase the size of your undo tablespace and find the optimum size considering your pick workload and longest running query. I mean your undo tablespace size should be enough to hold the undo data generated during the peak workload and provide read consistent version of the block for your longest running query. Again, it does not guarantees snapshot tooo old error could not happen. 2) in the second choise, you can change your undo tablespaces for guaranteed retention. In this case, despite the time of running of your longest query, you will not get snapshot too old errors. But, it measn that, during the heavy workload period, you can get errors with transactions which involve DML operations, if they could not find enough space for UNDO. So, i would increase the size of Undo tablespace and measure if it is ok or not. Oracle itself smartly choses which undo data is gonna be overwritten, even in the case of noguarantee undo tablespace. I.e. it will not overwrite the read consistent versions of undo blocks if there is some free(or expired) undo blocks.

Snapshot too old error during drop tablespace

Hi Experts
When we are doing BW reorg and steps followed are
1. created a newtablespace with source tablespace TABART class reference.
2. Export the source tablespace to the filesystem level.
3. DROP the source tablespace now.
4. Rename the new tablespace to source tablespace name.
5. Import
Here in the third step i have received snapshot too old error.
BR0301E SQL error -604 at location BrSqlExecute-1, SQL statement:
'/* BRSPACE */ drop tablespace PSAPADSOLD including contents and datafiles cascade constraints'
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small
BR1017E Execution of SQL statement 'drop tablespace PSAPADSOLD including contents and datafiles cascade constraints' failed
so i tried to rename the tablespace and set to offline and tried to import only 240 tables were imported compared to 24057 tables.Still the PSAPADS - Source tablespace shows 65000 elements.
my queries:
1. After Export of the tablespace how come the Source tablespace retain the tables.
2. why i could not able to drop the tablespace
I had increased the UNDO_RETENTION to 86400 my oracle version is 10.2.04.
Source table space PSAPADS is 80 GB and has only 30 GB data and the remaining are free.
PSAPUNDO was 17GB in size.
Kinldy suggest
Regards
Bala

Hi Stefa
Thanks for your reply.
how to find the System undo is still active.How to track which Undo which is active and their steps.
As per the metalink note our PSAPUNDO is Locally Managed Tablepsace hence the second workaround is applicable..
How to validate this will not give a problem again while i am doing reorganization.
When i checked a sap note 1039060 this note is applicable to windows i dont how it can be impleneted.
Whether any merge fix will help on this
Regards
Bala

FRM-92160: WEB Client Version too old & Vis R12.0.4 invalid objects

Hello all,
I'm installing Vision R12.0.4 in a server. That server used to contain Vision R12.0.0 which I upgraded to R12.0.4 but still had some invalid objects (I already submitted that problem in another thread). I installed the new vision instance to the same folder used to contain R12.0.0 vision after remove the old installation.
After all installation steps completed I tried to connect from my laptop but I got this error message :
FRM-92160: WEB Client Version too old
Had tried to uninstall all java from my laptop but still had the same error message. I had oracle form & report developer 6i and 10g in my laptop. Tried to remove that installation and cleaned the registry but failed to delete LEGACY_ORACLE_LOAD_BALANCER_GO_CLIENT and some other objects.
I checked the installation and found 35 invalid objects, do APPS compile and left with 32 invalid objects. Here are the invalid objects :
OWNER     OBJECT_NAME
APPS     IGCBG_CC_NUMBER_METHODS
APPS     IGCFG_CC_NUMBER_METHODS
ORDSYS     ORDIMGEXTCODEC_PKG
ORDSYS     ORDIMG_PKG
SYS     XMLGENFORMATTYPE
SYS     LCR$_ROW_LIST
SYS     LCR$_ROW_UNIT
SYS     AQ$_SRVNTFN_MESSAGE
SYS     AQ$_REG_INFO
SYS     AQ$_REG_INFO_LIST
SYS     DBMS_SUMADV
SYS     AQ$_REG_INFO_LIST
SYS     DBMS_XPLAN_TYPE
SYS     DBMS_XPLAN_TYPE_TABLE
SYS     AQ$_DESCRIPTOR
SYS     AQ$_SRVNTFN_MESSAGE
SYS     AQ$_EVENT_MESSAGE
SYS     AQ$_REG_INFO
SYS     AQ$_SRVNTFN_MESSAGE
SYS     MSG_PROP_T
SYS     AQ$_DESCRIPTOR
XDB     servlet-list46_T
XDB     servlet52_COLL
XDB     servlet47_T
XDB     xdbconfig58_T
XDB     servlet-config-type42_T
XDB     webappconfig65_T
XDB     sysconfig59_T
XDB     XDB$RESOURCE_T
XDB     protocolconfig60_T
XDB     sysconfig59_T
XDB     xdbconfig58_T
XDB     httpconfig64_T
XDB     protocolconfig60_T
XDB     httpconfig64_T
How to solve those problems? Thanks.

The following views will remain invalid in 12.0.4:
APPS IGCBG_CC_NUMBER_METHODS
APPS IGCFG_CC_NUMBER_METHODS
This is documented in 12.0.4 Release Note:549389.1
under "Installation and Upgrade Customers"Thanks for the info. At least it solved 2 of my problem rows :P
anyway, I'm sorry that I can't tried to solve the problem anymore cause the storage was needed for another installation so I'd to remove this problem instance. Maybe if I can try it again I'll let you all know. Thanks

Report file version too old

Hi, I hope I am in the right forum. I downloaded crystal report viewer 2008, but need to view a report that was created using an earlier version. The error message I get is as follows, " Report File version too old. This report was saved from a version of crystal report older than version 9 and cannot be viewed. To fix the problem please open and resave the report from a version of the crystal report designer application at least as recent as version 9".
How do I do this. I cant seem to get the older versions on the net anymore. Please help

The error message says "at least as recent as version 9".So, you can try with any version after 9.Following is the link to download a free trial version:
http: //www.businessobjects.com/product/freetrials.asp
You may try with Crystal Reports XI or Crystal Reports 2008

UNdo error (ora-01555) - Snapshot too old error

Hi,
If undo get filled and if we get a snapshot too old error then what is the solution for this error, plz give step by step solution for this.

You prevent ORA-01555 errors by
1) Setting UNDO_RETENTION equal to or greater than the length of the longest running query/ serializable transaction in the system
2) Ensuring the UNDO tablespace is large enough to accomodate the amount of UNDO generated over that period of time.
You would need to determine things like the length of your longest running query, the amount of UNDO getting generated, etc. and adjust your UNDO_RETENTION and UNDO tablespace accordingly.
Justin

Oracle 9i Snap shot too old error

Hello All,
We are using Oracle 9i. When I refresh M Views manually they are executing fine.
Initionally while creating M Views. I did a auto refresh for every 4 hours. After a week of sucessfull execution they error out giving snap shot too old error.
Upon my DBA request We have increased UNDO space from 500 MB to 2 GB.
And also removed AUTO refresh of M Views and created a procedure to refresh M View one after the other and scheduled to run 4 times a day.
Logic is to avoid parallel M View refresh.
However, non this helped to resolve snap shot too old error.
Now My DBA is asking increase the space by 2 more GB. I think the issue is some thing else.
Similar jobs are running perfectly in my Dev environment (DATA is almost same 10% varience) with UNDO size 500 MB.
Can you please help me here.
Thanks,
Ravi.

There are some questions,
first is about undo parameters, what is the value of undo retention and how many time execute the refresh.
second. Can you modify your undo to autoextend?
third. Who is using the undo?
This can be found in my friend Google:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
V$UNDOSTAT: histogram-like view that shows statistics for 10-minute intervals.
V$TRANSACTION: present time view providing information on current transactions.
V$SESSTAT: individual session statistics, which includes one for undo usage.

Oracle 9i: Snap Shot too old error while refreshing MV

Hello All,
We are using Oracle 9i. When I refresh M Views manually they are executing fine.
Initionally while creating M Views. I did a auto refresh for every 4 hours. After a week of sucessfull execution they error out giving snap shot too old error.
Upon my DBA request We have increased UNDO space from 500 MB to 2 GB.
And also removed AUTO refresh of M Views and created a procedure to refresh M View one after the other and scheduled to run 4 times a day.
Logic is to avoid parallel M View refresh.
However, non this helped to resolve snap shot too old error.
Now My DBA is asking increase the space by 2 more GB. I think the issue is some thing else.
Similar jobs are running perfectly in my Dev environment (DATA is almost same 10% varience) with UNDO size 500 MB.
Can you please help me here.
Thanks,
Ravi.

There are some questions,
first is about undo parameters, what is the value of undo retention and how many time execute the refresh.
second. Can you modify your undo to autoextend?
third. Who is using the undo?
This can be found in my friend Google:
http://oracledisect.blogspot.com/2008/05/who-is-using-your-undo-space.html
V$UNDOSTAT: histogram-like view that shows statistics for 10-minute intervals.
V$TRANSACTION: present time view providing information on current transactions.
V$SESSTAT: individual session statistics, which includes one for undo usage.

Snapshot too old error 1555

how to over come this problem practically

I can't speak for the original poster, of course.
But snapshot too old errors are what you get when, in order to produce the last piece of data at the finish time of some report, you have to roll the data you encounter in the buffer cache back to the state it was in at the start time.
A query which starts at 10.00am, for example, and finishes at 10.03 must see the data at 10.03 in the state it was at at 10.00am. So at the end of the query process, we have to do a '3 minute rollback'.
But if your query starts at 10.00am and doesn't finish until 10.53am, then you'd better hope 53 minutes of undo still exists in your database, because you're going to need to roll 10.53 data back to the state it was at 10.00.
The larger the time difference between the start and finish of a query, therefore, the more likely it becomes that the undo needed to generate a read consistent image won't be available, and that's when you get the 1555 signalled.
Most advice on 1555s say to increase the size of your rollback segments or your undo tablespace or increase the undo_retention time, so that the necessary undo **is** still available by the time you get to the query's finish time. But it's also a reasonable suggestion (though much harder to implement!) to tune the query so that the gap between start and finish time is much smaller than before. If a query used to take 53 minutes to complete but after tuning only takes 23 minutes to run, you've reduced the age of the undo you need available to produce the report by 30 minutes.
In other words, the common approach to 1555s is to increase the amount of undo that's available on the system. The approach being suggested here is to **reduce** the need for so much undo in the first place by reducing the length of time queries run for.

Version too old error

Similar Messages

Maybe you are looking for