I'm very new to SQL statements to update / manage records.
I have a very simple request and I have look into it online but it doesnt fully make sense as I am new.
My query is
Update [Data].[viewAppFieldList]
Set level = 308
Where fieldid = 23456
When I run it of course I get the error that it failed because it contains a derived or constant field.
Can someone explain why it is doing that, my assumption is because it is applicable in more than one place.
Secondly how do I go about manipulating it so this can be changed?
Thank you!
Related
I've searched and debugged the last couple of days how to obtain the
translated version of a DomainModel object in a CommandController in Typo3 v8.7.
In Typo3 4.5/4.7 I've done the following:
- input: DomainModel in default language
- build a query that finds the record with the l10n_parent matching the
given domain model
- obtain a new domain model with the desired sys_language_uid
Unfortunately this does not work in Typo3 v8.7 any more. I always get
the domain model for the default language.
I've traced this down to the method Typo3DbBackend::doLanguageAndWorkspaceOverlay
called via Typo3DbBackend::getObjectDataByQuery
The query returns the correct (translated) row (seen in the debugger and also the mysql query log), but then the variable
$row gets overwritten in doLanguageAndWorkspaceOverlay no matter how I
set the querySettings setLanguageOverlayMode and setLanguageMode.
So what is the correct way to get a translated domain model in a
CommandController?
UPDATE:
I think I'm a step further. If I add ->setQueryLanguage(1) to the query settings, doLanguageAndWorkspaceOverlay() tries to fetch the translated record for language = 1. But in order to succeed I need to trick the FrontendGroupRestriction class by setting $GLOBALS['TSFE']->gr_list = "0,-2";.
The array returned by doLanguageAndWorkspaceOverlay() now contains all translated entries, except the uid, which is still the uid from the record in the main language. The uid of the translated record is stored in _LOCALIZED_UID.
Now my problem now is that I still get the record in the main laguage because DataMapper->mapSingleRow() (called via DataMapper->map()) has some kind of object cache and thus returns the object in the default language (because the uid is still the one of the record in the main language).
All this seems a little hackish. So again my question: what is the correct way to get a translated domain model in a CommandController?
thanks,
mika
p.s.: I've set up the second language in the backend and creating a translated record works just fine. My question is just how to I get an existing translated record in a CommandController.
alternative solution:
based on the solution above, I decided that I can do almost everything
on my own. So what I do now is
i) create an independend querybuilder for the according table:
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->getQueryBuilderForTable($tableName);`
ii) select the record with the desired l10n_parent and sys_language_uid
$query = $queryBuilder->select('*')
->from($tableName)
->where($queryBuilder->expr()->eq('sys_language_uid', $langId))
->andWhere($queryBuilder->expr()->eq('l10n_parent', $parentUid))
->execute();
iii) fetch all records into an array
$rows = $query->fetchAll();
iv) invoke the DataMapper manually to get the object
$dataMapper = $this->objectManager->get(DataMapper::class);
$translated = $dataMapper->map($className, $rows);
I know it has nothing to do with the ModelRepository any more, but it
works quite fine for now...
that's all folks
My solution to the issue described above:
To avoid invoking the DataMapper as part of the query from
Typo3DbBackend, I used a raw query (argument for ->execute()) and get
back an array, that already went through language overlay etc.
BUT: in
the array the '_LOCALIZED_UID' is still available. So I overwrite the
uid with the value from '_LOCALIZED_UID' and invoke the DataMapper
manually. Quite cumbersome and very hackish to overcome the Typo3
backend shortcomings...
Query Hints not working in Eclipse Link 2.3.2/2.6.1 when used to fetch data from second level Cache
Used Hints,
#QueryHint(name = "javax.persistence.cache.retrieveMode", value = "USE"),
#QueryHint(name = "javax.persistence.cache.storeMode ", value = "USE")
Tried with below options.
1. Added JPA Hints to Named query itself
#NamedQuery(
name = TestEntity.FIND_BY_CODE,
query = "select t from Test t where t.code = :code",
hints = {
#QueryHint(name = "javax.persistence.cache.retrieveMode", value = "USE"),
#QueryHint(name = "javax.persistence.cache.storeMode ", value = "USE") })
2. Adding hints to the Entity Manager Itself after injecting it
em.setProperty("javax.persistence.cache.retrieveMode", CacheRetrieveMode.USE);
em.setProperty("javax.persistence.cache.storeMode", CacheRetrieveMode.USE);
3. Added JPA hints at the time of Query execution
em.createNamedQuery(TestEntity.FIND_BY_CODE,
AlertCategoryType.class).setHint("javax.persistence.cache.retrieveMode", CacheRetrieveMode.USE)
.setHint("javax.persistence.cache.storeMode", CacheStoreMode.USE)
.setParameter("code", code).getSingleResult();
None of the above usage of hints worked. Then i tried debugging on three different options what i found is,
the Data Base Query which formed after setting these hints is passing hints as key/value pair below.
eclipselink.query.hints => {javax.persistence.cache.retrieveMode=USE, javax.persistence.cache.storeMode=USE}
Where eclipselink.query.hints is the key even when we have set the JPA hints. This is something we don't have control over to change this.
But when i pass Eclipse Link provided hints as below , It started working as expected and the Results are fetched from Cache and not from the DB.
eclipselink.query.hints => {eclipselink.query-results-cache.size=500, eclipselink.query-results-cache=true}
It means That When we use Eclipse Link it only recognizes Eclipse Link provided hints according to the key[ above shown] we see in Query.
Please suggest any work around to get the JPA Hints working
Environment I'm using is
Eclispe Link 2.3.2/2.6.1
Runnin fin serve Glassfish 4.1[payara]
Java8/JEE7
The query hint you state is working (eclipselink.query-results-cache) is completely unrelated - it creates a new cache for the query results so that next time you execute that same query, the results are already there, so it does not need to execute the query again. This is outside (above an beyond) the second level cache.
The settings you refer to as not working affect the second level cache. Without more information, I'm going to state they are likely working as expected. Just because your query goes to the database does not mean the cache isn't being used. Caching entities is very different than caching the results to a query. If the query results are not cached, unless you have in-memory querying enabled, most read-all type queries must go to the database to determine what entities need to be built and returned. EclipseLink will then use those results to check the cache- if the entities already exist, they are returned as is - this avoids the overhead of rebuilding entities from the data.
You can check if your entity has been cached by using a em.find() or read query that uses the ID value. The cache is indexed by ID, so it will not need to go to the database to figure out which entities you want.
I have a Microsoft Access form that is being supplied (somehow) by a query. The query contains three tables linked together via their respective primary and foreign keys, and the form displays data quite happily.
The strange thing (as far as I'm concerned) is the ability of the form to then allow data entry using the query.
However, if the user creates a new record, the whole thing seems to have problems due to a required field in the [table2] table.
SELECT [table1].*
,[table2].JobNo
,[table2].PlannedDateOC
,[table3].DateJobStarted
,[table1].PlanNo
FROM (
[table1] LEFT JOIN [table2] ON [table1].PlanNo = [table2].PlanNo
)
LEFT JOIN [table3] ON [table2].JobNo = [table3].JobNo
ORDER BY [table2].PlannedDateOC
,[table1].PlanNo;
According to the users, this form worked perfectly prior to conversion from Access 97/2003 format to Access 2010 (2007 file format).
Could anyone clarify whether this (the fact that it should work) is legitimate, and if this process would work in either version of Access, if so? The concept of being able to use a query for data entry is quite alien to me.
Let me know if you need further clarification.
NOTE:
One thing of note, here, is that I did move some of the fields into the form header so that they were always visible as the rest of the form scrolls. I don't know if this will have any side effects on the performance of the form.
Above query will allow you to insert data into [table1] when all not null fields have their values and make sure only table1.fields are getting dirty when new record is inserted.
Can any one help me why this error occurs when i update using sqlDataadapter with join query
Dynamic SQL generation is not supported against multiple base tables.
You have a "join" in your main query for your dataset (The first one in the TableAdapter with a check by it). You can't automatically generate insert/update/delete logic for a TableAdapter when the main query has multiple tables referenced in the query via a join. The designer isn't smart enough to figure out which table you want to send updates to in that case, that is why you get the error message.
Solution. Ensure that your main query only references the table you want the designer to write insert/update/delete code for. Your secondary queries may reference as many tables as you want.
It was in the case that i was trying to set value for identity column in my datarow. Simply i deleted the code to set value for identity column and it will work.
My Scenario:
Database:
uin [primary, identity]
name
address
Whenever i tried to set the datarow("uin") the error occurs. But works fine with datarow("name") and datarow("address").
Hope it works for you too
I have a (very simple and standard) UPDATE statement which works fine either directly in Query Analyser, or executed as a stored procedure in Query Analyser.
UPDATE A
SET
A.field1 = B.col1
, A.field2 = B.col2
FROM
tblA AS A INNER JOIN tblB AS B
ON A.pk1 = B.pk1 AND A.pk2 = B.pk2
Problem is when i execute the same stored proc via microsoft ADP (by double-clicking on the sproc name or using the Run option), it says "query ran successfully but did not return records" AND does NOT update the records when i inspect the tables directly.
Before anyone even says "syntax of MS-Access is different than SQLServer T-SQL", remember that with ADP everything happens on the server and one is actually passing thru to T-SQL.
Any bright ideas from any ADP gurus out there?
Gotcha. Responding to my own question for the benefit of anyone else.
Tools / Options / Advanced / Client-Server Settings / Default max records is set at 10,000 (presumably this is the default). Change this to 0 for unlimited.
My table had 100,000+ rows and whatever set of 10,000 it was updating was difficult to find ( among a sea of 90,000+ un-updated rows ). Hence the update did not work fully as expected.
Try and see whether the query gets executed on the SQL Server using SQL profiler.
Also, I think you might need to close the linked table & re-open it to see the updated records.
Does that work?
Run the query with SQL PRofiler running. Before you start the trace add in all the error events. This will give you any errors that the SQL Server is generating that the Access ADP might not be showing correctly (or at all).
Feel free to post them here.
Just as a reference, here's a paper I wrote on Update Queries that discusses some of the issues associated with when the fail.
http://www.fmsinc.com/microsoftaccess/query/snytax/update-query.html
I seem to remember that I always got the "didn't return any rows" message and had to simply turn off the messaging. It's because it isn't returning any rows!
as for the other - sometimes there's a primary key issue. Does the table being updated have a primary key in SQLServer? If so, check the view of the table in Access - sometimes that link doesn't come through. It's been a while, so I could be wrong, but I think you may need to look at the design view of the table while in access and add the primary key there.
EDIT: Additional thought:
in your debugging, try throwing in print statements to see what the values of your inputs are. Is it actually picking up the data from the table as you expect when you execute from access?