I have a query that I wrote using Query Analyzer. It works in the Analyzer but when I run it in Excel I get an invalid column name error. the error does not list the entire column name. If I put square brackets around the entire column name the error lists the entire column name.
If i run the code as follows.
Select
tblarInvoice.shipfromlocation
From
tblarInvoice
Where
tblarInvoice.dateshipped >= '10/01/2014'
I get the error of:
Invalid column name'shipfrom'
If I run the code with square brackets around it i get the error of:
Invalid column name'shipfromlocation'
Likely something to do with the driver being used.
Perhaps there's a limit on column length.
Try and alias the column Name to something shorter.
It may also have trouble with the name 'FROM' in the column name.
Could you create a view in the database that selects from the table but aliases the column name .
The driver may parse the SQL see FROM think it's a reserved word and give up. The [] may put you beyond a 30 character limit as well... so ... try something different use column name alias and or select from the view?
SELECT tblarInvoice.shipfromlocation as sfl
Root Cause is one of two things or a combination:
When processing the SQL string the Driver sees "FROM" and throws an error
When you wrap the name in [] it extends the field name to be > 30 characters which in some drivers is a limit.
You could isolate root cause by altering the alias on the view to be something like sFROMLocation If you get an error you know the driver has probelms parsing column names with FROM in them.
If you alter it to sFroLocation does it then work?
Additionally you could set the column name to tblarinvoiceshipfrolocationtest if an error is returned you know that column names > 30 are problems for the driver being used.
then change it to
tblarinvoiceshipfrolocationtst if it works then you know a 31 length name doesn't work. a 30 does. again evidence driver can't support column names longer than 30 characters.
Just depends if you want to get to root cause :P
Related
I am in charge of adding new employees to our speech recognition and gamification systems.
When I get a batch of tickets, I compile a bunch of data into a spreadsheet that I then reference when adding those users to the systems (Which unfortunately do not have a JSON/CSV upload option or anything similar)
To save some time with compiling, I've started exporting a bunch of data from our database and our HR management system into that sheet, and then using the new employee's email to XLOOKUP all the other data fields.
For one of our systems, it has a strict character limit, and the format for the username is "cde\firstname.lastname". This is no problem to CONCATENATE normally, but it has a strict character limit, so if the user has a hyphenated last name, I will basically dump everything after the hyphen.
At first I tried a simple formula using a combination of LEFT and FIND -1 to find the hyphen, and then take everything to the left of it. This obviously doesn't end up working because I get a #VALUE! for anyone without a hyphen in their last name.
I tried using IFERROR to say "OK try to return the last name without a hyphen, otherwise just return the last name", but for some reason when I put the reference in the Return_If_Error portion, it doesn't recognize it as a reference.
So I am looking for a formula that will work with a LOOKUP'd value and only give me what's before a hyphen, but otherwise will still just give me the last name.
The baseline formula I have, that just looks up and concatenates the first and last into the "cde\firstname.lastname" is:
=CONCATENATE("cde\",LOWER(XLOOKUP(G578,Sheet4!M:M,Sheet4!B:B)),".",LOWER(XLOOKUP(G578,Sheet4!M:M,Sheet4!C:C)))
To expand on the comments, you've got the right idea, just use an IF statement for testing if the string contains "-", then use the normal string functions like FIND, LEFT, etc. to pick out the things you want.
For example:
="cde/"&
LEFT(H1,FIND(".",H1)-1)&
IF(ISNUMBER(FIND("-",H1)),MID(H1,FIND(".",H1),FIND("-",H1)-FIND(".",H1)),
MID(H1,FIND(".",H1),FIND("#",H1)-FIND(".",H1)))
I have table as below. In first column name of the company and in next column corresponding country.
The look up value of company name is not exact match in this case
The company name from table is a subset of the look up value.
Reference Table as below:
The output expected is as follows:
I tried using formula=VLOOKUP(LEFT(B14,LEN(B14)-4),$H$2:$I$4,2,FALSE)
but it only help solve first entry and not for others. The output I got with above formula is as below:
Request help in sorting this issue.
Thanks
Maybe try the following:
=INDEX(I:I,SUMPRODUCT(ISNUMBER(FIND(H$3:H$4,B14))*ROW(H$3:H$4)))
However, this might be troublesome when you anticipate a word can be a sub-string inside another, eventually giving wrong results. If that won't be the case, that's great, but if so, then maybe safer would be:
=VLOOKUP(FILTERXML("<t><s>"&SUBSTITUTE(TEXTJOIN(" ",1,H$3:H$4,B14)," ","</s><s>")&"</s></t>","//s[preceding::*=.]"),H$2:I$4,2)
I'm trying to do a database full text search and struggling to get it to work.
Since I'm working with date fields, I deleted my full text index, set all my blank date fields to a fictitious date (3/15/2050), compacted the db and then rebuilt the full text index.
However, I am still getting the error for this query string:
(FIELD Form CONTAINS 'Opp') AND (FIELD Topic CONTAINS 'A') AND (FIELD DateTeam >= 3/1/2019) AND (FIELD DateTeam <= 3/31/2019)
I didn't have the single quotes in there initially, but tried it as a suggestion from another post. I also tried putting # before and after my dates, but no luck there either.
What am I missing? My customer is getting frustrated.
You didn't post the verbiage in the exception, nor say what Domino version you were using, so this is somewhat guesswork.
It could be that the UNK table (Domino's internal field catalog) thinks the field is a string field. The first value stored in a field is the type that the FT index uses to determine the indexed data type. Of course any type can be stored in the NSF data but the FT code tries to limit this type of search to fields it believes will work.
Now if those CONTAINS values are actually = values, then DQL can help you. We'll be putting CONTAINS as a verb into DQL in V11, but it (DQL) can certainly perform your date range term. Just a thought.
-John Curtis
This might help: https://www-10.lotus.com/ldd/dominowiki.nsf/dx/full-text-syntax
As far as I know date values must be in [] to work.
A good start is to test your formula in the client with the FT search function instead of altering your code.
By the way: you can shorten your formula omitting the FIELD keyword and putting the field name also in [].
I tried this in my mail database:
(FIELD Form CONTAINS "Memo") AND (FIELD Subject CONTAINS "the") AND (FIELD PostedDate >= 3/1/2019) AND (FIELD PostedDate <= 30/6/2019)
And it works correctly. So double quotes instead of single, and you might have to check whether your date format corresponds with the server's.
The approach I was taking was correct. The problem, however, was that my update agent to set all the date fields had a typo in it so it wasn't setting the right fieldnames to dates. My oversight. Once I found that and corrected it, I retraced my steps and it all works as intended now. Thank you to all for helping me find the solution.
For anyone else, I took these steps:
Open database properties and delete the full text index
Run this command on the console to compact the db: lo compact folder/db.nsf -c
Run an agent against all the docs to set the date fields to a fictitious date
Open database properties again and create a new full text index
When completed, run this command on the console: load updall -f folder/db.nsf
Run the agent again to reset the fictitious dates to blanks
I'm trying to read an Excel sheet from an XLS or XLSX file in memory using Delphi 7. When possible I use automation to read the cells one by one, but when Excel is not installed, I revert to using the ADO/ODBC Jet driver.
I connect using either
Provider=Microsoft.Jet.OLEDB.4.0; Data Source=file.xls;Extended Properties="Excel 8.0;Persist Security Info=False;IMEX=1;HDR=No";
Provider=Microsoft.ACE.OLEDB.12.0; Data Source=file.xlsx;Extended Properties="Excel 12.0;Persist Security Info=False;IMEX=1;HDR=No";
My problem then is that when I use the following query:
SELECT * FROM [SheetName$]
the returned results do not contain the empty rows or empty columns, so if the sheet contains such rows or columns, the following cells are shifted and do not end up in their correct position. I need the sheet to be loaded "as is", ie know exactly from what cell position each value comes from.
I tried to read the cells one by one by issuing one query of the form
SELECT F1 FROM `SheetName$A1:A1`
but now the driver returns an error saying "There is data outside the selected region". btw I had to use backticks to enclose the name because using brackets like this [SheetName$A1:A1] gave out a syntax error message.
Is there a way to tell the driver to select the sheet as-is, whithout skipping blanks? Or maybe a way to know from which cell position each value is returned?
For internal policy reasons (I know they are bad but I do not decide these), it is not possible to use a third party library, I really need this to work from standard Delphi 7 components.
I assume that if your data is say in the range B2:D10 for example, you want to include the column A as an empty column? Maybe? Is that correct? If that's the case, then your data set, when you read the sheet (SELECT * FROM [SheetName$]) would also return 1 million rows by 16K columns!
Can you not execute a query like: SELECT * FROM [SheetName$B2:D10] and use the ADO GetRows function to get an array - which will give you the size of the data. Then you can index into the array to get what data you want?
OK, the correct answer is
Use a third party library no matter what your boss says. Do not even
try ODBC/ADO to load arbitrary Excel files, you will hit a wall sooner or later.
It may work for excel files that contain a single data table, but not when you want to cherry pick data in a sheet primarily made for human consumption (ie where a single column contains some cells with introductory text, some with numerical data, some with comments, etc...)
Using IMEX=1 ignores empty lines and empty columns
Using IMEX=0 sometimes no longer ignores empty lines, but now some of the first non empty cells are considered field names instead of data, although HDR=No. Would not work anyway since valules in a column are of mixed types.
Explicitly looping across cells and making a SELECT * FROM [SheetName$A1:A1] works until you reach an empty cell, then you get access violations (see below)
Access violation at address 1B30B3E3 in module 'msexcl40.dll'. Read of address 00000000
I'm too old to want to try and guess the appropriate value to use so it works until someone comes with yet another mix of data in a column. Sorry for having wasted everybody's time.
I am developing a SSIS package, trying to update an existing SQL table from a CSV flat file. All of the columns are successfully updating except for one column. If I ignore this column on truncate, my package completes successfully. So I know this is a truncate problem and not error.
This column is empty for almost every row. However, there are a few rows where this field is 200-300 characters. My data conversion task identified this field as a DT_WSTR, but from what I've read elsewhere maybe this should be DT_NTEXT. I've tried both and I even set the DT_WSTR to 500. But none of this fixed my problem. How can I fix? What data type should this column be in my SQL table?
Error: 0xC02020A1 at Data Flow Task 1, Source - Berkeley812_csv [1]: Data conversion failed. The data conversion for column "Reason for Delay in Transition" returned status value 4 and status text "Text was truncated or one or more characters had no match in the target code page.".
Error: 0xC020902A at Data Flow Task 1, Source - Berkeley812_csv [1]: The "output column "Reason for Delay in Transition" (110)" failed because truncation occurred, and the truncation row disposition on "output column "Reason for Delay in Transition" (110)" specifies failure on truncation. A truncation error occurred on the specified object of the specified component.
Error: 0xC0202092 at Data Flow Task 1, Source - Berkeley812_csv [1]: An error occurred while processing file "D:\ftproot\LocalUser\RyanDaulton\Documents\Berkeley Demographics\Berkeley812.csv" on data row 758.
One possible reason for this error is that your delimiter character (comma, semi-colon, pipe, whatever) actually appears in the data in one column. This can give very misleading error messages, often with the name of a totally different column.
One way to check this is to redirect the 'bad' rows to a separate file and then inspect them manually. Here's a brief explanation of how to do that:
http://redmondmag.com/articles/2010/04/12/log-error-rows-ssis.aspx
If that is indeed your problem, then the best solution is to fix the files at the source to quote the data values and/or use a different delimeter that isn't in the data.
I've had this issue before, it is likely that the default column size for the file is incorrect. It will put a default size of 50 characters but the data you are working with is larger. In the advanced settings for your data file, adjust the column size from 50 to the table's column size.
I suspect the
or one or more characters had no match in the target code page
part of the error.
If you remove the rows with values in that column, does it load?
Can you identify, in other words, the rows which cause the package to fail?
It could be the data is too long, or it could be that there's some funky character in there SQL Server doesn't like.
If this is coming from SQL Server Import Wizard, try editing the definition of the column on the Data Source, it is 50 characters by default, but it can be longer.
Data Soruce -> Advanced -> Look at the column that goes in error -> change OutputColumnWidth to 200 and try again.
I've had this problem before, you can go to "advanced" tab of "choose a data source" page and click on "suggested types" button, and set the "number of rows" as much as you want. after that, the type and text qualified are set to the true values.
i applied the above solution and can convert my data to SQL.
In my case, some of my rows didn't have the same number of columns as the header. Example, Header has 10 columns, and one of your rows has 8 or 9 columns. (Columns = Count number of you delimiter characters in each line)
If all other options have failed, trying recreating the data import task and/or the connection manager. If you've made any changes since the task was originally created, this can sometimes do the trick. I know it's the equivalent of rebooting, but, hey, if it works, it works.
I have same problem, and it is due to a column with very long data.
When I map it, I changed it from DT_STR to Text_Stream, and it works
In the destination, in advanced, check that the length of the column is equal to the source.
OuputColumnWidth of column must be increased.
Path: Source Connection manager-->Advanced-->OuputColumnWidth