I have case sensitive problems in TYPO3 v 8.7 LTS. System is sometimes mocking that a file is missing. The error message is
Oops, an error occurred!
File /archiv/ABCD.pdf does not exist.
Allthough the file is there. When I put the file in lowercase to fileadmin "abcd.pdf" than FAL isn't mocking around. But seems after a while it still is mocking.
At least I am not understanding where the problem lies. Because even if ABCD.pdf is there and in the right place I get warnings.
I checked DB integrity several times. But still no luck. Afterwards delete the cache in INSTALL TOOL.
I found DB tables where files are stored. Is there a way, that I manually can update this tables and get rid of these error message?
Make sure the checkbox "case sensitive" on the storage is equal to your file system.
Run the FAL index update scheduler task.
That should align the DB values again
Related
I have two .mdb files with one being a copy of the other. When there are made changes to the original mdb i want to merge them into my copy, which itself may have changed meanwhile.
As I require to use access 2002 Version Theres a lack of helpful plugins but Id be fine with Just using SaveAsText and LoadFromText Methods.
The Problem is - when i change the file i generated with SaveAsText, the checksum at the top of the file does Not Match the Content anymore and Access throws an Error 3011 when I Try to do LoadFromText.
Does anyone know about a way to work around this issue?
I have problems translating Modelica models with Dymola 2020: When I try to translate the models, the following error message appears:
"unknown internal error in Dymola".
The model was translating and simulating a couple of days ago, and the same model still runs on the computer of other colleagues. I didn't change the compiler in between nor the Dymola version. I've also restarted the computer but the problem persists.
Also, other models are still translating, so not all models are affected by this error.
Does anyone have a clue how to debug this error? Thank you very much for all hints!
The most likely explanation would be some weird setting of some flag.
You can see if you have any odd settings of normal flags by:
Dymola 2020: Edit>Options>General>Flags... Check "Non-default"
Dymola 2020x: Tools>Options>General>Flags... Check "Non-default"
(If it is a non-Boolean setting it is a bit messier.)
That is assuming it is really the same model and there is no difference in any model in the path (including working directory).
Frankly speaking, if you get "unknown internal error in Dymola" you should report it to technical support at Dassault Systèmes (through your reseller), and let them debug it.
It is not your job to debug such errors.
Have you tried to delete the content from the working directory (WD)?
Sometimes there are artifacts, which mess up the compilation of a specific model.
You can check where it is, using the
GUI, File -> Working Directory -> Copy Path and paste it in the Explorer
Command line typing cd, which returns the path to the WD
Then make sure that there are no important files in the WD (usually .mo files) and finally delete the full content of the directory.
Note: You should ensure that the WD is a local path (otherwise performance can take a serious hit). Besides that it is usually a good idea to have the WD separated form the directory where models are stored.
Site works fine. Suddenly it will through an error. When clicking "flush system cahce" the error will go away for a some time. Anything from minuttes to severaæ hours.
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1247602160:
Unknown column 'tx_my_domain_model_formular.rel_formular' in 'where
clause' |
TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException
thrown in file
/webserver/typo3/src/6.2.15/typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php
in line 862.
It is correct that the columns does not exist. But how to preceed in finding the error after this? Where is the sql generated that causes the site to crash?
UPDATE
A check "myParentObj->getChildObj instanceof myChildObjClass" used to work just fine. After changing myParent model to lazy load the ChildObj, then the class of childObj changed from childObjClass to a lazyLoadClass... I am not sure but I guess that is in turns somewhere somehow caused the core error seen in the log.
How to investigate further I simply cannot work out. Eg. store all DB calls in a file og DB to analyze after the error occours.
First
Please take time to write a good question. For a good question you'll get a good answer. It doesn't have to be perfect (not everyone is a native english speaker) but please reread your question.
Answer
If all fields are defined correctly, just run a DB compare from within the installtool.
If not, you need to define the DB-fields in your extension correctly.
Is this your own extension? When doing the query that triggers the error you could call execute(true) to generate the actual SQL statement and debug from there.
When I go to check something into MorphX VCS right now, I get the following message:
Cannot create a record in SysVersionControlMorphXRevisionTable (SysVersionControlMorphXRevisionTable).
The record already exists.
With things that have already been checked out once, I've been able to resolve this with a get latest and then a new checkout/check in. However, when it comes to doing an Add, I'm completely stuck. Is there a resolution to this or have we completely borked our VCS?
Note: this error is only given when we try to check in from a development project. Checking in directly on the AOT does not give this issue.
Just look at the table SysVersionControlMorphXRevisionTable (in SQL if you can't access) and see what the duplicate record could be. The unique index is ItemPath and Version. I doubt you'll see anything here though.
It's most likely an issue with the call in this method \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\latestVersionNumber where it's trying to get the current highest revision and is being called by \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\create.
Put a breakpoint in the create method line #48 and see what revision.Version is, and before the insert, check in SQL if the ItemPath/Version already exists in SQL.
I'd guess it's probably a server/client-caching issue. To resolve, refresh all of your client caches under Tools>Caches. If this doesn't resolve, and it's a good idea to do anyway, copy these menu items:
\Menu Items\Action\SysFlushAOD
\Menu Items\Action\SysFlushData
\Menu Items\Action\SysFlushDictionary
\Menu Items\Action\SysFlushReportServer
To a new menu item and change the property RunOn = Server. Then run these and it'll flush your server caches. If this still doesn't work, try restarting the AOS.
If this doesn't work, your users application user cache files might be corrupt. Close your client and delete the *.auc and *.kti files in %LocalAppData% folder (Typically C:\Users\[user]\AppData\Local) and reopen your client.
In the environment you are using, have you restored a copy of another database somewhat recently?
Edit: Now knowing that you did a DB restore, there is a good chance your GLOBALGUID was reused and/or is causing caching issues. See here for more info about how/why this happens.
You should probably stop your AOS and run these SQL commands:
UPDATE SYSSQMSETTINGS SET GLOBALGUID = '00000000-0000-0000-0000-000000000000'
DELETE FROM SYSCLIENTSESSIONS
DELETE FROM SYSSERVERSESSIONS
Are/were you also having issues with batches running? (Somewhat related, but I'm mainly just curious on this question)
While using tAccessInput component in my job, it showing error like,
It may not be a database that your application recognizes, or the file may be corrupt.
But, it all the connections and database/table names are valid in my job.
What can be the problem. and how can i resolve it.
Metioning the exact DBVersion is more important for tAccessInput/tAccessOutput.
Like Access 2003/Access 2007 and associated database file name.