I am getting following error while running command line version of Liquibase V3.5.5
Unexpected error running Liquibase: Validation Failed:
1 changes have validation failures
setColumnRemarks is not supported on mysql, PosMS1-V0.0.1-
104.xml::1531369854279-1::otalio (generated)
liquibase.exception.ValidationFailedException: Validation Failed:
1 changes have validation failures
setColumnRemarks is not supported on mysql, PosMS1-V0.0.1-
104.xml::1531369854279-1::otalio (generated)
I was able to use Liquibase to add remarks to column while renaming and creating new columns, but it throws an error when I compute the diff of two databases which has only change in adding remark.
Related
I am getting this error when using dbt cli 0.21.1 with Snowflake:
Encountered an error: Database Error 001003 (42000): SQL compilation error: syntax error line 1 at position 31 unexpected '<EOF>'. syntax error line 1 at position 30 unexpected '.'.
... when running "dbt build". I have stripped down my models to the minimum and get the same error whatever I do. I have done "dbt clean". The results of "dbt debug" and "dbt parse" look fine.
In the dbt.log file, I can see it fails on a Snowflake command:
create schema if not exists FT.
... with the SQL compilation error message shown above.
I found the same error in the Snowflake query history, with the same command text. So I tried it by hand in the Snowflake console. Lo and behold, it works fine without the trailing period, but Snowflake produces exactly this error with that trailing period.
So it seems like dbt and Snowflake disagree about whether a SQL command should end with a period. Which one has a bug? Or is there a way to tell one or the other to change?
I forgot that I had created a generate_schema_name macro -- and it was messing up the schema name, turning it into an empty string. The create schema command was trying to create a schema named "FT." but because the schema name was blank, it ended up as "FT." -- and the trailing period confused me.
Mea culpa.
Hope this description ends up helping someone else who makes the same mistake.
I am trying to copy a database from old.fdb to new.fdb which has a slightly different structure like additional tables or columns. So, far I've tried using IBPump but it doesn't support FDB it's for GDB.
I tried using FBCopy but it gives me an error
*** IBPP::SQLException ***
Context: Statement::Prepare( INSERT INTO TABLE1 ("FIELD1","FIELD2","FIELD3")
VALUES (?,?,?) )
Message: isc_dsql_prepare failed
SQL Message : -104
Invalid token
Which I think is because my database dialect is 1. Also, I tried using dbMigration .NET but the connection isn't being established because the charset of the database is NONE.
I don't know what to do next. I will really appreciate any help or suggestions.
I use liquibase diff generate the diff between dev mysql and prod mysql, I see there exist some change set like:
When I run the diff file, it shows exception like:
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-984::davy (generated)
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-985::davy (generated)
setColumnRemarks is not supported on mysql, db/changelog/V1.1.0_prod_uat.xml::1524893614482-986::davy (generated)
at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:276)
at liquibase.Liquibase.update(Liquibase.java:198)
at liquibase.Liquibase.update(Liquibase.java:179)
at liquibase.integration.spring.SpringLiquibase.performUpdate(SpringLiquibase.java:317)
at liquibase.integration.spring.SpringLiquibase.afterPropertiesSet(SpringLiquibase.java:269)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706)
How to resolve this problem?
Object's comment update (Liquibase's set*Remarks) is not supported for some databases, including MySQL. So immediate fix could be to remove this action from your change log.
In my project we generating change sets by comparing (with liquibase diffChangeLog) 2 schemas, and setColumnRemarks actions are included although they cannot be executed afterwards. So I'm just removing these actions from resulting change sets.
I am afraid a proper solution would be to add appropriate MySQL SQL generator implementation to Liquibase.
I'm trying to delete some rows from a BigQuery table (using standard SQL dialect):
DELETE FROM ocds.releases
WHERE
ocid LIKE 'ocds-b5fd17-%'
However, I get the following error:
Query Failed
Error: Invalid schema update. Field packageInfo has changed mode from REQUIRED to NULLABLE
Job ID: ocds-172716:bquijob_2f60927_15d13c97149
It seems as though BigQuery doesn't like deleting rows with a REQUIRED column. Is there any way around this?
It has been a known limitation that BigQuery DML doesn't work with tables with required fields (see https://cloud.google.com/bigquery/docs/reference/standard-sql/data-manipulation-language#known_issues).
We are in the process of removing this limitation. We whitelisted your project today. Please try running your query again in the same project. Let us know if the problem is still there, or if you want to have more projects whitelisted.
I'm trying to create a temp table and process two data flows using the temp table. It is in a sequence container and if I just execute the container it run perfect but when the entire package is ran it returns this error:
Information: 0x4004300A at V-AccidentCodesBase, SSIS.Pipeline:
Validation phase is beginning.
Error: 0xC0202009 at V-AccidentCodesBase, Insert into Temp Table [69]:
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error
code: 0x80040E14.
An OLE DB record is available. Source: "Microsoft SQL Server Native
Client 11.0" Hresult: 0x80040E14 Description: "Statement(s) could
not be prepared.".
An OLE DB record is available. Source: "Microsoft SQL Server Native
Client 11.0" Hresult: 0x80040E14 Description: "Invalid object name
'##TmpAccidentCode'.".
Error: 0xC004706B at V-AccidentCodesBase, SSIS.Pipeline: "Insert into
Temp Table" failed validation and returned validation status
"VS_ISBROKEN".
Error: 0xC004700C at V-AccidentCodesBase, SSIS.Pipeline: One or more
component failed validation.
Error: 0xC0024107 at V-AccidentCodesBase: There were errors during
task validation.
I would set the DelayValidation property to True. You may get away with just setting this on the Sequence Container, or you may need to repeat that setting on child objects, e.g. your Data Flow Task.
Also faced the same error message. The issue was permissions on the database for the user that runs the ETL (a service account). Make sure the user that runs the package has enough permissions to execute the query.
As other guys mentioned, the error may happen due to different reasons. In my case, I realized that I have tried to convert some NULL to int in Script section of SSIS. Something like :
ProductsBuffer.ProductId = Int64.Parse(reader["ProductId"].ToString());
so the fix was easy. I just checked the field before converting, to make sure it is not null:
if (reader["ProductId"] != DBNull.Value)
ProductsBuffer.ProductId = Int64.Parse(reader["ProductId"].ToString());
In my case I switched from OleDB to SQNCLI and it worked :/
I ended up solving the problem which was overloading tempDB. When I slowed the process down to one command to tempDb at a time it all ran through smoothly.
I faced the same error, in my case, I was using SSIS to import data from an excel file into a couple of tables.
I used 2 differents files and it failed with one and worked with the other, after some review I found that I was referring to the name of the excel sheet within the package, so the excel sheet has to be named EXACTLY (i think it is case sensitive) as you used on the SSIS package
I'm using VS 2017. I wonder if after a while it forgets your "saved" database passwords, because mine worked fine for days, then just quit working out of the blue, gave the VS_ISBROKEN error. After I reentered the password for one of my database connections--despite the fact I had checked the Save Password checkbox previously--it started working again.