I've bumped into a problem when trying to update my database. I Changed a FK and the virtual property inside my model. When I try to update the database now I'm getting this error:
Either the parameter #objname is ambiguous or the claimed #objtype (COLUMN) is wrong.
On this line code it stops the update-database:
RenameColumn("dbo.test", "test_Id", "ProgramId");
And the -verbose attribute is showing me that this line of code is giving me the error:
EXECUTE sp_rename #objname = N'dbo.test.test_Id', #newname = N'ProgramId', #objtype = N'COLUMN'
I don't know why it is giving me this error, does anyone know what is going wrong with the automatically generated migration file?
Thanks, Brent
I tried whay you said in my project which was using EF Core, I didn't get just RenameColumn in migration class, I got :
DropForeignKey(...) ,
DropIndex(...) ,
DropColumn(..)
and then AddColumn(...),
CreateIndex(...) and
CreateForeignKey(...)
and of course worked fine when I updated database.
But I searched for your issue , it seems SQL get confused somehow, the all solutions for problems like you, were saying use [] around tableName or ColumnName, it seems you have another name like these names and SQL can't specify them.
If you just tell me more about your entities before and after changes, I can follow your footstep and get error like you.
Related
Transformation Parse Warning [<<P M Parse Warning>> <<Invalid constant sun-expression>> <<Expression Error>> [TO_DATE]:invalid string for converting to Date
… t:TO_DATE(s:s:”,s:s:’YYYYMMDD’)
……….
AND SATIS_TARIHI = >>>> TO_DATE($$RUN_DATE,’YYYYMMDD’)<<<<];
How can I solve this?
This is the first time I encounter this error. Normally, this is a daily routine for our job. The parameter is successfully added to the mapping and all the other things seem okay. I’d appreciate your help.
I tried to start the workflow and got this error.
You need to define a $$RUN_DATE in mapping. Currently its not defined in mapping or its null in parameter file.
You need to set a default value in mapping like 20221221 for today.
Or else you can set it up in a parameter file like this
[folder.workflow_name]
[folder.session_name]
$$RUN_DATE=20221221
Considering this is your daily routine and up till now it has been working fine, I assume this is not a new development and no recent changes have been made. Apparantly PowerCenter got an invalid value for the parameter.
Check you parameter file and how it gets generated.
Was the process of generating paramfile executed without issues?
Was there enough storage space?
Can you verify the paramfile contents?
Can you regenerate it?
Can you modify it and provide some value manually?
Feel free to get back with some updates for more help if your problem won't get resolved by checking the items on the list above.
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.
I was working on a tsql project, and I have noticed that the existing code used a syntax that I have not seen before. They have put a dollar sign in front of the database name for fully qualified address.
Here is one example :
SELECT c.AccountCode, FROM **[$(SmartAdmin)]**.dbo.Customers c
If I rename the database name as SmartAdmin.dbo.Customers, Visual Studio throws error says "contains an unresolved reference to an object".
It appears to be a Visual Studio related thing, can anyone explain what is this and
whether I can remove it.
Please see the attached screenshots, the last one comes from project solution file.
The [$(SmartAdmin)] syntax is used in an SSDT project to reference objects in other databases. To be precise, it is SQLCMD syntax.
If you have a database reference to SmartAdmin, and if the reference is set up so that [$(SmartAdmin)] properly references it, then that is not the problem. It looks like the problem is the other two references to [SmartAdmin]. Change them to look like [$(SmartAdmin)].dbo.whatever.
Example of why these references are useful: I just edited a stored procedure I had in SSDT to misspell a column name. Within seconds, the column name was underlined in red. I then deleted the database reference the column name depended on. The red underline went away. I added the database reference back, and the column was once again underlined in red. I corrected the column name, and the red underline went away.
Without the database reference, I would have had to wait until the stored procedure was deployed, or possibly executed, to see the error. With the database reference, I found out about the problem in the editor. Just like code.
It appears to me that your database is actually called $(SmartAdmin)
As the error suggests "contains an unresolved reference to an object". which means when you change the database name to SmartAdmin, it cannot find a database with this name on server.
If you want to change the database name you will need to execute the following statement and then you will be able to use that name in your statements.
USE master;
GO
EXEC sp_renamedb '$(SmartAdmin)', 'SmartAdmin';
GO
USE SmartAdmin; --<-- Now you will be able to connect to this database
GO -- without the dollar ($) sign.
This issue relates to Database Project External Database References. When you add another solution to a database project, you can specify the "Database Variable Name", in my case, it is $(SmartAdmin).
Please see this link for more information.
Thanks everybody for answering my question.
Does anybody know how to use the "Conditions" feature in the "Mapping Details" option of the Model.
I have tried adding Conditions like "IsDeleted = False" or "IsDeleted = 0" and nothing works. Just get errors.
Many thanks.
It seems that one cannot use a mapped property. Once I removed this, the condition worked. However this means that one cannot update this property via EF, and instead one has to use raw DDL via ExecuteStoreCommand.
Hope this helps someone. It got me scratching my head !!
I have an action in a model that adds a record to a table. It works fine when I test it by typing values in to the browser, but is failing when I test it with PHPUnit. The frustrating part is that I don't really know how to diagnose the problem.
The unit test has a (rather long) $data array, and the problem occurs when I call the dbTable->insert($data) method. The log shows:
CRIT (2): Application Error
CRIT (2): Request Parameters
How can I get more information on these errors? The line following the offending line is not executed.
Thanks!
Ok, so I had a boolean field in the DB that was not nullable. It showed a default value of 0, so I assumed that I didn't need to provide this field in the insert statement. Seems I was wrong.
As soon as I provided a value for this field it worked fine.
Something else that confused this issue is that I had assumed I'd get a more descriptive error in my log if was such a simple error ...