We updated a working TYPO3 8.7.17 to 9.5, made all necessary steps in the Update Wizards, cleared all caches and yet receive this error in the frontend (backend works fine):
There is no entry in the $TCA array for the table
"pages_language_overlay". This means that the function enableFields()
is called with an invalid table name as argument.
Error is called in /html/typo3/typo3_src-9.5.0/typo3/sysext/frontend/Classes/Page/PageRepository.php line 1588
Since 9.5 LTS is only a few days old, I could not find anything helpful anywhere else, except for the entry wiki entry covering the error #1283790586 InvalidArgumentException. But that does not apply to our project.
Anybody who has had this error after upgrading?
The table "pages_language_overlay" does not exist anymore. The records are merged into the pages table. You can find more information about it in the notes:
https://docs.typo3.org/typo3cms/extensions/core/Changelog/9.0/Important-82445-MigratePagesLanguageOverlayIntoPages.html
Perhaps you have an activated extension, which uses the old table explicitly (perhaps an old pi based extension). Try to disable your extensions and enable them step by step to find out which extension throws the error. If you found out which extension throws the error you can dig deeper into it.
Related
what I am doing
I am following a tutorial of solr and training on exampledocs folder
where i am getting issue
I inserted all the documents in exampledocs folder and got result in query
But when i made a change to a field and re inserted one document, i am unable to get the result.(document got inserted successful)
Information Required
I had not changed any configuration files, i am just following a tutorial
In tutorial he is getting the answer but i am not getting.
i am using solr version 4.9.1
after insert i did "optimize" and "reload" in "core admin" page, but still i am not getting the changes. ('Windows7 64bit' is my pc)
please help. (i can provide any info )
I have 2 instances of Odoo v9 running in the same server (Ubuntu 14.04). I want to make changes (install modules, change source code or anything) in the developement instance and after confirming they are OK, move the changes to the Production Instance. Is there anyway of doing that without repeating the whole process of development?
Thank you.
As I can understand you do not want to stop the production instance.
If they are only XML files you might be able to get away by only updating the module from the frontend (Apps-> Your Module -> Update. Although if you have modified the __openerp__.py file inside your module you have to enter the debug mode and click Update Apps List first of all.
For changes in files that are inside the static folder of your module, you do not need to stop the server. Although, your users must click ctr + shift + R in order to flush their caches and bring to their browsers the new content.
For Python source code I am afraid that you have to stop both instances of the server so that the code can be correctly recompiled.
(See note 1 on this)
In the end you should stop and update everything because unexpected things might pop up at random times due to resources not been properly updated.
Note 1: The Python documentation about the compilation of Python modules above others mentions:
As an important speed-up of the start-up time for short programs that
use a lot of standard modules, if a file called spam.pyc exists in the
directory where spam.py is found, this is assumed to contain an
already-“byte-compiled” version of the module spam. The modification
time of the version of spam.py used to create spam.pyc is recorded in
spam.pyc, and the .pyc file is ignored if these don’t match.
So theoretically if you modify fileA.py in a module and a new fileA.pyc is generated the server will be able to interpret and use it. In any case I had an issue with two instances running where the py file was creating the field and the XML file was using it and the server reported that a filed had not been created for the XML view, that means that the server did pick up and parse the XML file but did not recompile the py.
So I was looking for installing an Oracle 12c database on my Windows 8 laptop, so that I could learn much of SQL(after posting my last question).
I have downloaded all the needed zips. obviously while trying I got error:
[INS-30131] Initial setup required for the execution of installer validations failed.
Additional Information:
- Framework setup check failed on all the nodes
- Cause: Cause Of Problem Not Available
- Action: User Action Not Available
Summary of the failed nodes
hp
- Version of exectask could not be retrieved from any node
- Cause: Cause Of Problem Not Available
- Action: User Action Not Available
Well after looking into many posts on SO, I figured out that it needs some hidden User account (C$). I got steps for setting up such a account but unfortunately they are not working for me.
Following the path as: Control Panel>Administrative Tools> Computer Management>Shared.
As mentioned in steps across internet, there is no option for me to create a new account.
Apart from that, I have tried changing my Username and also I have tried using default Administrator account but nothing seems working.
I am pretty sure this is not new so somebody out there must have a solution to this issue. Pls advice...
This is the description of the error, I saw it, but was trying to find an idea how to fix it.
Anyway, I solved it by renaming the volume group and updating accordingly the fstab and the grub.conf.
I am trying run SOA Suite and when I execute startWeblogic.sh I got the following message error:
Unresolved reference to WseeFileStore by [<domain name>]/SAFAgents[ReliableWseeSAFAgent]/Store
at weblogic.descriptor.internal.ReferenceManager.resolveReferences(ReferenceManager.java:310)
at weblogic.descriptor.internal.DescriptorImpl.validate(DescriptorImpl.java:322)
at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:332)
at weblogic.management.provider.internal.DescriptorManagerHelper.loadDescriptor(DescriptorManagerHelper.java:68)
at weblogic.management.provider.internal.RuntimeAccessImpl$IOHelperImpl.parseXML(RuntimeAccessImpl.java:690)
at weblogic.management.provider.internal.RuntimeAccessImpl.parseNewStyleConfig(RuntimeAccessImpl.java:270)
at weblogic.management.provider.internal.RuntimeAccessImpl.<init>(RuntimeAccessImpl.java:115)
... 7 more
Does anyone know how to fix this error?
I am running the system over 64 bits Suse
The quick and dirty way to get your admin server back up:
cd to <domain name>/config
Back up config.xml just in case
Edit config.xml, find and remove the <saf-agent> tags that point to your non-existent WseeFileStore
When you have the admin server back up. You can look at the Store-and-Forward Agents and Persistent Stores links to see what is already configured there. It sounds like a SAF agent was somehow created but the backing Persistent Store was not.
You can always created the Persistent Store later and add that SAF agent back in if you need it.
This happens simply because the automated tool used to adapt the config.xml file to the new cluster structure is... well, far from efficient.
It can create all other relevant structures ok, but the <saf-agent> entry is wrongly created.
Just open and look briefly to the config.xml file and you should see that something is not right with this entry.
I will use my environment as an example for this situation:
I have a single cluster with two managed servers named osb1 and osb2. Both are administered by the cluster's AdminServer and all these components are in a single machine called rdaVM. The whole domain was created with the Configuration wizard and, upon the first AdminServer start, I've got that dreadful error for quite some time.
The solution does reside in the config.xml file located in <DOMAIN_HOME>/config/config.xml
When I opened this file in the editor and did a quick search for WseeFileStore I got some curious entries:
<jms-server>
<name>WseeJmsServer_auto_1</name>
<target>osb1</target>
<persistent-store>WseeFileStore_auto_1</persistent-store>
</jms-server>
<jms-server>
<name>WseeJmsServer_auto_2</name>
<target>osb2</target>
<persistent-store>WseeFileStore_auto_2</persistent-store>
</jms-server>
and
<file-store>
<name>WseeFileStore_auto_1</name>
<directory>WseeFileStore_auto_1</directory>
<target>osb1</target>
</file-store>
<file-store>
<name>WseeFileStore_auto_2</name>
<directory>WseeFileStore_auto_2</directory>
<target>osb2</target>
</file-store>
but looking at the offending entry:
<saf-agent>
<name>ReliableWseeSAFAgent</name>
<store>WseeFileStore</store>
</saf-agent>
Obviously there's something missing here. Looking at the <DOMAIN_HOME> I could see two folders there: WseeFileStore_auto_1 and WseeFileStore_auto_2. So no WseeFileStore and hence that annoying error. Also, the saf-agent element doesn't have a target.
Solution: using just the underlining logic, I adapted the <saf-agent> entry to:
<saf-agent>
<name>ReliableWseeSAFAgent_auto_1</name>
<target>osb1</target>
<store>WseeFileStore_auto_1</store>
</saf-agent>
<saf-agent>
<name>ReliableWseeSAFAgent_auto_2</name>
<target>osb2</target>
<store>WseeFileStore_auto_2</store>
</saf-agent>
I.e, created a <saf-agent> for each of the cluster's managed servers, targeted each entry to a managed server and added the _auto_# suffix, where # is the ordering number for each managed server, to the <name> and <persistent-store> entries.
After it, I was able to run the startWebLogic.sh script without problems (from this source at least...)
I got the following SQLException: "invalid options in all7"
Upon googling the error message, the ONLY hits I saw were Oracle error lists which pinpointed the error at "ORA-17432: invalid options in all7". Sadly, googling for the error # brought up only combined lists with no explanation for the error, aside from this page that said "A TTC Error Message" as the entire explanation.
The error happens when a Java program retrieves data from a prepared statement call executing a procedure that returns a fairly large, but not unreasonable, # of rows via a cursor.
I can add the stack trace from the exception as well as condensed code, but I assume that's not terribly relevant to figuring out what "ORA-17432: invalid options in all7" means.
Context:
Error seemed to have appeared when the Java program was migrated from Oracle 9 OCI to Oracle 10.2 thin client. The procedure, when run directly against database (via Toad) works perfectly fine and returns the correct cursor with correct data and no errors.
This seems to be something data specific (result set size may be?) since running that same exact code against a different currency as a procedure parameter (which returns much smaller resultset) works 100% fine.
This is almost certainly not something you're going to have control of. It looks like a problem with the way your thin driver is using the two-task common (TTC) protocol. One thing to note is that this sort of thing can be very sensitive to the version of the driver you are using. Make absolutely certain that you have the latest version of the JDBC driver for the combination of the version of Java you're using and the version of Oracle on the server.
Akohchi - you were in the right area though not quite correct. The explanation obtained via Oracle Support call was that this version of Java (1.3) was not compatible with new Oracle. Java 1.4 fixed the issue.