I get the following error when I add fields (even commented out) into my query into DBT.
I am using DBT cloud, running off snowflake.
This runs fine - it even has the table from which I want the fields in the join at the bottom.
However, as soos as I put in the fields - even commented out, I get the error in the title.
Any one have any idea why this is happenning.
so in the end, I found out that somehow a non-ANSI character (like a deadspace) crept into my script between copying code to and from the DBT interface to SSMS. Still not sure how this happened. None the less, DBT has a python module that parses the text, and this python module was having an issue with that character.
So in the end, I simply had to retype my code... and then it worked.
Related
I'm attempting to provide support for a legacy ASP/MSSQL web application - I wasn't involved in the development of the software (the company that built it no longer exists) & I'm not the admin of the server where it's hosted, I just manage the hosting for the owners of the site via a reseller account. I'm also not an ASP developer (more a PHP guy), and am not that familiar with it beyond the basics - updating DB connection strings after server migrations, etc.
The issue is that the site in question stores the content of individuals pages in an MSSQL database, and much of the content includes links. Almost all of the internal links on the site are format like "main.asp?123" (with "123" being the ID of a database row). The problem is, starting sometime in the last 8 months or so*, something caused the links in the DB content to show up as "main.aspÀ123" instead - in other words, the "?" character is being replaced by the "À" character (capital A with grave accent). Which, of course, breaks all of those links. Note that Stackoverflow won't allow me to include that character in the post title, because it seems to think that it indicates I'm posting in Spanish...?
(*unfortunately I don't know the timing beyond that, the site owners didn't know when the issue started occurring, so all I have to go by is an archive.org snapshot from last October, where it was working)
I attempted to manually change the "?" character in one of the relevant DB records to "?" (the HTML entity for the question mark), but that didn't make any difference. I also checked the character encoding of the HTML code used to display the content, but that doesn't seem to be the cause either - the same ASP files contain hard-coded links to some of the same pages (formatted exactly the same way), and those work correctly: the "?" doesn't get replaced.
I've also connected to the database directly with the MSSQL Management Studio Express application, but couldn't find any charset/character encoding options for either the database or the table.
And I've tried contacting the hosting provider, but they (M247 UK, in case anyone is curious) have been laughably unhelpful. The responses from them have been along the lines of "durrrrrr, we checked a totally different link that wasn't actually the one that you clearly described AND highlighted in a screenshot, and it works when we check the wrong link, so the problem must be resolved, right?" Suffice it to say, I wouldn't recommend them - used to be a customer of RedFox hosting, and the quality of customer has dropped off substantially since M247 bought them.
Any suggestions? If this were PHP/MySQL, I'd probably start by creating a small test script that did nothing but fetch one of the relevant records and display it's contents, to narrow down the issue - but I'm not familiar enough with ASP to do that here, at least not without a fair amount of googl'ing (and most of the info I can find is specific to ASP.net instead).
Edit: the thread suggested as a solution appears to be for character encoding issues when writing to MSSQL, not reading from it - and I've tried the solutions suggested in that thread, none make any difference.
Looks like you're converting from UNICODE to ASCII somewhere along the line...
Have a look at this to get a quick demo of what happens. In particular, pay attention to the ascii derived from inr, versus the ascii derived from unicode...
SELECT
t.n,
ascii_char = CHAR(t.n),
unicode_char = NCHAR(t.n),
unicode_to_ascii = CONVERT(varchar(10), NCHAR(t.n))
FROM (
SELECT TOP (1024)
n = ROW_NUMBER() OVER (ORDER BY ao.object_id)
FROM
sys.all_objects ao
) t
WHERE 1 = 1
--AND CONVERT(varchar(10), NCHAR(t.n)) ='À'
;
I found a workaround that appears to do the trick: I was previously trying to replace the ? in the code with ? (took out the ; so that it will show the code rather than the output), which didn't work. BUT it seems to work if I use &quest instead.
One thing to note, it seemed that I was originally incorrect in thinking that the issue was only affecting content being read/displayed from the MSSQL DB. Rather, it looks like the same problem was also occurring with static content being "echo'd" by code in the ASP scripts (I'm more of a PHP guy, not sure the correct term is for ASP's equivalent to echo is). Though the links that were hardcoded as static (rather HTML being dynamically output by ASP) were unaffected. Though chancing the ? to &quest worked for those ones too (hardest part was tracking down the file I needed to edit).
I wrote a query using the query tool in pgadmin 4. Now I want to download the results as a csv. I´ve got two problems with that.
The 'Download as CSV'-button does not work sometimes. Especially when the result contains 1000+ rows.
When I finally have a csv and I want to open it, this message is all I see:
"'ascii' codec can't encode character u'\xbb' in position 26: ordinal not in range(128)"
Since I´m fairly new to all of this, could someone enlighten me to what is wrong?
On your questions:
The broken CSV download was a known bug that was fixed in pgAdmin v1.5 (Bug summary at the login-required https://redmine.postgresql.org/issues/2253; the gist is that there were multiple issues with exporting JSON data and Unicode). If you're not on that version, try updating and see whether you continue to have the issue.
You didn't specify where you're seeing that message regarding encoding, but the character referenced in the error is a "Right-Pointing Double Angle Quotation Mark" (») (http://www.codetable.net/hex/bb).
Does anyone know exactly why these types of issues happen using a script component that can be “fixed” by deleting and re add the same code to make fix this type of issue? Why would metadata change when you delete and re add code? what happens inside the engine when this happens? What kind of issue could it ever fix to delete and re add a script component, copy the same code and rewire it?
I can reproduce at will with the following steps:
Took a working package with a script component and two output buffers. The script component has additional input columns and output columns setup for the second output buffer that are not being populated yet by the source query (OLE DB source SQL command) yet. Only one column is being populated in the second output buffer from the source query .
Copied in a new source query with additional columns for the second output buffer.
Run the package. Get the error message Column data type DT_DBDATE is not supported by the PipelineBuffer class.
Comment out the two lines for the second output buffer, run the package, the package runs successfully:
RedactedOutputBuffer.AddRow();
RedactedOutputBuffer. RedactedColumnName = Row. RedactedColumnName;
Uncomment the same two lines. The package still works. So the package is now exactly the same as when it did not work.
Well, no, it's not really a bug, it's more like SSIS doesn't try to be clever and fit square pegs in round holes.
I mean the error message is pretty clear, innit? The PipelineBuffer class doesn't have any methods to handle data types of DT_DBDATE. So it throws you a UnsupportedBufferDataTypeException:
The exception that is thrown when assigning a value to a buffer column
that contains the incorrect data type.
Anyway, since you didn't print your full error message stack, it's hard to say exactly but my guess is it tried to call SetDateTime (or GetDateTime ) on your busted column. So when you set your source query, it sets the pipeline buffer's data type as DT_DBDATE, but when you comment it out, let it run, then uncomment it out, it has converted the pipeline buffer's data type to DT_DBTIMESTAMP, which is compatible with SetDateTime or whatever method is being called from the PipelineBuffer class which is throwing your error.
Anyway, this MSDN post should give you a little more flavor on what you're seeing, but the bottom line is make sure that the field coming out of your source query is correctly identified as the field type you want it to be in your destination. If that's a SQL Server datetime field, you either need to cast it as datetime in your source query or use a Data Conversion component to explicitly cast it for your script component.
This is my code
CURSORSETPROP("Buffering",4)
SELECT course
APPEND BLANK
replace course.name with thisform.txt_course.value
this works fine during the development of the project, however,when i convert the project to .exe file, I cant write to the table and it brings the error
Cannot update the cursor course, since it is read-only
I've manage to find for what i thought was the solution which is the code below
CURSORSETPROP("Buffering",4)
SELE * FROM course INTO CURSOR cCourse READWRITE
APPEND BLANK
replace cCourse.name with thisform.txt_course.value
But the problem is that this code does not write to the table. I mean there was no error about being the table read-only, however there are no additional file added/appended to the table "course"
Can anyone lend me a hand here, i have no idea where to find a solution.
Vfp Error 111 itself, Cannot update the cursor ..., can be caused by a DBF table being included in the VFP Project Manager. If so, you can right click it in the PM and "Exclude".
There is however a mistake in the code you posted: The CURSORSETPROP line affects the alias in the current "work area", which could be anyone or even none, unless you would use the cAlias parameter of the function.
(Or, as a second best way, do the Select before the CursorSetProp().)
I have a CSV file with quote text delimiters. Most of the 90000 rows are fine, but I have a few rows that have a text field that contains both a quote and a comma. For example the fields value would be:
AB",AB
When Delimited this becomes
"AB"",AB"
When SQL 2005 attempts to import this I get errors such as...
Messages
Error 0xc0202055: Data Flow Task: The column delimiter for column "Column 4" was not found.
(SQL Server Import and Export Wizard)
This only seems to happen when a quote and comma are in a text value together. Values like
AB"AB which becomes "AB""AB"
or
AB,AB which becomes "AB,AB"
work fine.
Here are some example rows...
"1464885","LEVER WM","","B","MP17"
"1465075",":PLT-BC !!NOTE!!","","B",""
"1465076","BRKT-STR MTR !NOTE!","","B",""
"1465172",":BRKT-SW MTG !NOTE!","","B","MP16"
"1465388","BUSS BAR !NOTE!","","B","MP10"
"1465391","PLT-BLKHD ""NOTE""","","B","MP20"
"1465564","SPROCKET:13TEETH,74MM OD,66MM","ID W/.25"" SETSCR","B","MP6"
"S01266330002","CABLE:224"",E122/261,8 CO","","B","MP11"
The last row is an example of the problem - the "", causes the error.
I've had MAJOR problems with SSIS. Things that Access, Excel and even DTS seemed to do very well, SSIS chokes on. Variable record-length data is another problem but, yes, these embedded qualifiers are a major problem. Especially if you do not have access to the import files because they're on someone else's server that you pay to gain access to and might even be 4 to 5 GB in size! Cant just to a "replace all" on that every import.
You may want to check into this at Microsoft Downloads called "UnDouble" and here is another workaround you might try.
Seems like with SSIS in SQL Server 2008, the bug is still there. I dont know why they havent addressed this in the parser but its like we went back in time with SSIS in basic import functionality.
UPDATE 11-18-2010: This bug still exists in SSIS. Amazing.
How about just:
Search/replace all "", with ''; (fix all the broken fields)
Search/replace all ;''; with ,"", (to "unfix" properly empty fields.)
Search/replace all '';''; with "","", (to "unfix" properly empty fields which follow a correct encapsulation of embedded delimiters.)
That converts your original to:
"1464885","LEVER WM","","B","MP17"
"1465075",":PLT-BC !!NOTE!!","","B",""
"1465076","BRKT-STR MTR !NOTE!","","B",""
"1465172",":BRKT-SW MTG !NOTE!","","B","MP16"
"1465388","BUSS BAR !NOTE!","","B","MP10"
"1465391","PLT-BLKHD ""NOTE""","","B","MP20"
"1465564","SPROCKET:13TEETH,74MM OD,66MM","ID W/.25"" SETSCR","B","MP6"
"S01266330002","CABLE:224'';E122/261,8 CO","","B","MP11"
Which seems to run the gauntlet fine in SSIS. You may have to step 3 recursively to account for 3 empty fields in a row ('';'';'';, etc.) but the bottom line here is that when you have embedded text qualifiers, you have to either escape them or replace them. Let this be a lesson in your CSV creation processes going forward.
Microsoft says doubled double quotes inside double quote delimited fields just don't work. A fix is planned for the end of 2011...
In the mean time we will have to use workarounds like described in the other answers.
I would just do a search/replace for ", and replace it with ,
Do you have access to the original file?