Up until the latest PTFs were applied to our iSeries I was able to compile RPG programs that used sqltype clob and clob_file (ex dcl-s xml_data SQLTYPE(CLOB:10000000);)
now I get the compile time error RNF3308 20 a 001001+ Keyword name is not valid; the keyword is ignored.
Anyone else run into this issue?
solved issue. Looks like one of our compile options was changes or reverted after a ptf was applied. needed to set RPGPPOPT(*LVL2) in compile.
Related
I have upgraded my dbt version to 1.0.0 yesterday night and ran few connection test. It went well . Now when i am running the my first dbt example model , i am getting below error , even though i have not changed any code in this default example model.
Same error i am getting while running dbt seed command also for a csv dataset . The csv is utf-8 encoded and no special character in it .
I am using python 3.9
Could anyone suggest what is the issue ?
Below is my first dbt model sql
After lots of back and forth, I figured out the issue. This is more like fundamental concept issue.
Every time we execute dbt run, dbt will scan through the entire project directory ( including seeds directory even though it is not materializing the seed ) [Attached screenshot below].
If it finds any csv it also parsed it .
In case of above error, I had a csv file which looks follows :
If we see the highlighted line it contains some symbol character which dbt (i.e python) was not able to parse it causing above error.
This symbol was not visible earlier in excel or notepad++.
It could be the issue with Snowflake python connector that #PeterH has pointed out .
As temporary solution , for now we are manually removing these character from Data file.
I’d leave this as a comment but I don’t have the rep yet…
This appears to be related to a recently-opened issue.
https://github.com/dbt-labs/dbt-snowflake/issues/66
Apparently it’s something to do with the snowflake python adapter.
Since you’re seeing the error from a different context, it might be helpful for you to post in that issue that you’re seeing this outside of query preview.
I am setting up a new user for liquibase (3.5.3). When we run the following command:
liquibase --defaultsFile=Config /Liquibase.properties --logLevel=Info
We get this error message:
--contexts=initial update Unexpected error running Liquibase: Unknown parameter: '#Liquibase.properties '
SEVERE 2/7/17 11:39 AM: liquibase: Unknown parameter:
'#Liquibase.properties'
liquibase.exception.CommandLineParsingException: Unknown parameter:
'#Liquiba se.properties'
at liquibase.integration.commandline.Main.parsePropertiesFile(Main.java:
476)
at liquibase.integration.commandline.Main.run(Main.java:164)
at liquibase.integration.commandline.Main.main(Main.java:103)
For more information, use the --logLevel flag
I thought there may have been a funny character in the file, so we recreated it, but still received the same error. We also, took a working copy of a properties file from another project and modified it. This also produced the same result.
Any ideas on what is going wrong or thoughts on how to fix it, would be greatly appreciated.
m
 is a UTF-8 Byte order mark (or short BOM). Some text editors write one by default when using UTF-8 encoding, even though, most programs do not understand it.
In your case, liquibase seems to be one of the programs which do not understand the BOM and treat it as the beginning of a parameter. To fix this, make sure you save the file as UTF-8 without BOM if your editor supports this option, or alternatively, as ASCII or ISO 8859 (ANSI) if you only use characters defined in ASCII.
Suddenly I'm getting an error in _types.h on the line with typedef. How can I track this down?
#ifdef __GNUC__
typedef __signed char __int8_t;
#else /* !__GNUC__ */
This is pretty much always caused by a syntax error just prior to whatever included the file with the actual error.
So, have a look in the file that (indirectly) included _types.h. You likely have an unbalanced (.
Usually these cryptic errors in system header files result from your having other code (perhaps in another header file which was #import'ed earlier) that is missing a closing parenthesis. Often whenever you get strange compile errors, you have to look at the lines of code that the compiler encountered before the reported line and see if that earlier code was properly terminated.
Every time i start my server in production mode i get this error mesage
Invalid US-ASCII character "\xC2"
(in /home/rzaartz/rails/school/app/assets/stylesheets/application.css.scss)
Pls any help about this kind of error
I had this same problem when running rake assets:precompile . For me the problem was in normalize.css---a character in the first line comment wasn't being understood by the asset compiler.
If you are including this file, replace the 'center-dot' with a dash. (Note that this change has been committed already by polarblau). If you're not using normalize look somewhere in your sass includes for the center-dot and remove it.
(for fellow googlers)
As stated here, a simple solution is to explicitely declare you scss encoding in the main(s) scss :
#charset "UTF-8";
I hate Xcode 4! It crashes all the time and finally it gives me an error in CABase.h file which is an library header file that I am not allowed to modify..
I don't even know how this file is broken.
How to fix this problem? It complains like
"Expected *before*
Expected '=',',',';','asm' or '_attribute_' before 'extern'
Also, how can I completely remove Xcode on my Mac and re-install?
You probably just have a simple error, perhaps in a header which is included prior to CABase.h. Use a "divide and conquer" strategy to locate it.
To answer your last question:
$ sudo /Developer/Library/uninstall-devtools –mode=all
This happened to me just because I had the letter 's' at the beginning of one of my implementation files. I must have missed the cmd key when cmd+s for saving the file. Luckily, another compile error discovered this and removing the 's' fixed both errors.
For example,
s//
// GraphingViewController.m