I made a simple query function as this: =QUERY(range,"select *",1), in my Google Spreadsheet, but the results dose not show any letters, it shows only fields that contains numbers.
Study this link
Syntax
QUERY(data, query, [headers])
data - The range of cells to perform the query on.
Each column of data can only hold boolean, numeric (including
date/time types) or string values.
In case of mixed data types in a single column, the majority data type
determines the data type of the column for query purposes. Minority
data types are considered null values.
Just format your range as a plain text using Format > Number > Plain text option, the below images show how to do it:
Related
For some time now I have the impression that a field and a column are the same thing in SQL server but today I stumbled across the statement that they are not actually the same thing. It was stated that a field is the intersection of a row and a column, so if a table has 10 rows and 10 columns it will have 100 fields in total.
I looked at Microsoft Docs and this is what it says:
A column is collection of cells aligned vertically in a table. A field is an element in which one piece of information is stored, such as the eceived field. Usually, a column in a table contains the values of a single field.
In this case then it looks like they are not the same thing.
I would highly appreciate it if someone can clarify this! Thank you in advance!
A field is part of a row, not a table, a "column of a row", if you will.
However, a lot of people use these terms interchangeably, and you can (read: have to) often deduce what they actually meant by the context of the sentence.
In some contexts, a field may refer to an element within a data value, where a column contains the entire data value. A common example is a date data type, where the month, day, and year are fields within the column. Spatial data types (e.g., the PostGIS data type in Postgres) is another example, where the x coordinate, y coordinate, and spatial reference ID are all fields within the column. Some kinds of identifiers have application-specific fields within them, where, for example, the first two characters carry some information, the next four characters convey some other information, etc. In cases like these, the distinction between column and field is important.
This question already has an answer here:
Failing to read String value from an excel column
(1 answer)
Closed 3 years ago.
I have a SSIS package which sources from an Excel file, performs a lookup in SQL, and then writes the fields from the lookup to a flat file. For some reason, any of the fields in the SQL table that are of data type varchar 256 are not getting written. They are coming in as nulls. My other fields, including varchar 255, are coming across fine. I have tried flat file and Excel as destination with no luck.
I've tried converting the varchar with a data conversion to both 256 and to a Unicode string and no luck.
Even when I preview a simple query in the source component (ex: select lastname from xyz), the preview shows the lastname as null. It doesnt show other fields that have different data types as nulls.
This is usually a case when the excel driver only reads the first 8 rows of data and misinterprets the correct data type because of the lack of data it's checking. Here are some of the known issues from the Microsoft site: Reference
Issues with importing
Empty rows
When you specify a worksheet or a named range as the source, the driver reads the contiguous block of cells starting with the first non-empty cell in the upper-left corner of the worksheet or range. As a result, your data doesn't have to start in row 1, but you can't have empty rows in the source data. For example, you can't have an empty row between the column headers and the data rows, or a title followed by empty rows at the top of the worksheet.
If there are empty rows above your data, you can't query the data as a worksheet. In Excel, you have to select your range of data and assign a name to the range, and then query the named range instead of the worksheet.
Missing values
The Excel driver reads a certain number of rows (by default, eight rows) in the specified source to guess at the data type of each column. When a column appears to contain mixed data types, especially numeric data mixed with text data, the driver decides in favor of the majority data type, and returns null values for cells that contain data of the other type. (In a tie, the numeric type wins.) Most cell formatting options in the Excel worksheet do not seem to affect this data type determination.
You can modify this behavior of the Excel driver by specifying Import Mode to import all values as text. To specify Import Mode, add IMEX=1 to the value of Extended Properties in the connection string of the Excel connection manager in the Properties window.
Truncated text
When the driver determines that an Excel column contains text data, the driver selects the data type (string or memo) based on the longest value that it samples. If the driver does not discover any values longer than 255 characters in the rows that it samples, it treats the column as a 255-character string column instead of a memo column. Therefore, values longer than 255 characters may be truncated.
To import data from a memo column without truncation, you have two options:
Make sure that the memo column in at least one of the sampled rows contains a value longer than 255 characters
Increase the number of rows sampled by the driver to include such a row. You can increase the number of rows sampled by increasing the value of TypeGuessRows under the following registry key:
Redistributable components version - Registry key
Excel 2016 - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\Excel
Excel 2010 - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\Excel
I loaded an Excel file into an SQL table. The Excel file, one field consists of VARCHAR data (of data type general). When loaded into an SQL table, some of these values are prefixed with zero.
Example: in the Excel file it is 1081999 the same value become 01081999 in the SQL table.
What might be the reason for this ?
Excel will hide leading 0's as it identifies the fields content as a number and displays it as such. I would assume that the excel worksheet does indeed contain these leading 0's and they are simply not shown by Excel. If you change the type of the column from General to Text do they show up??
As a side note, if these are indeed numbers you should be storing them in a numeric datatype in the database...
I have an input spreadsheet that needs to get sorted by date. The current format of the date is in the UK format (dd/mm/yyyy) but I need it in yyyy-mm-dd (actually I don't, I just need to sort it and that format is the most foolproof way of sorting). This all needs to be done in VBA as it's part of a bigger project that allows a bunch of data collation at once. The other problem is that the input sheet can be quite large (150,000+ rows). So, while I could parse through each row of data and change it around to the way I need, this would be horrifically slow and is NOT an option.
Currently I'm using this bit of code to format the date to yyyy-mm-dd:
inputGADRSheet.Columns(7).NumberFormat = "yyyy-mm-dd"
But, Excel outsmarts me and assumes that the date format of the column is originally in the US format (mm/dd/yyyy) which messes everything up and half of the values in the column don't meet that requirement (days above the 12th) so they don't get formatted at all. Is there any way to tell Excel what format the current data is in? That way it won't just assume that it's in the US date format...
Is the solution to change my Excel region to the UK. I assume this could be done using VBA, but it seems risky...
If your data is already in an Excel column, you can't reinterpret the values: Excel date values are (internally) number, 1 representing 1900-01-01. After the data has been (mis-)interpreted by Excel there's no way back.
The question is: Where do you get the input data sheet from? If the dates are entered correctly, reformatting is possible without any problem and does not affect sorting (which depends only on the numeric value of the date). If your data comes from a text file (probably .csv-kind), be sure to read ii as text and use Excel worksheet functions or VBA to interpret the values.
In my Access database, I have a table called customers. In this table I have a column called DateEntered. The data type for the field is short text.
The values in this column are not coherent - they come in several variations:
MM-DD-YYYY,
MMDDYYYY and
MM/DD/YYYY.
There doesn't seem to be any standard set.
My goal is to select all customers from 2012. I tried
select *
from customers
where DateEntered <('%2013') AND >('%2012');
but it comes up blank when I run it.
Can anyone point out what I'm failing to do correctly & more importantly explain why exactly this query doesn't work in Access? From my understanding of SQL (not very advanced) this should work.
Another variant)
select * from customers where RIGHT(DateEntered, 4) = '2012'
If you have control over the database and application code, the best way to handle this is to use an actual Date field instead of text in the table.
One way to handle this would be to add a new field to the table, write a query or two to correctly convert the text values to actual date values, and populate the new field.
At this point, you would then need to hunt down the application code the refers to this field in any way and adjust to treat the field as a date, not text. This includes your insert and update statements, report code, etc.
Finally, as a last step, I would rename the original text field (or remove it altogether) and rename the new date field to the original field name.
Once you fix the problem, querying against the field will be a piece of cake.
Alternatively, if you can't alter the table and source code, you can use the date conversion function CDATE() to convert the text value to an actual date. Note that you may need to guard against non-date entries (NULL or empty string values, as well as other text values that aren't really dates in the first place). The IsDate() function can be your friend here.
If you have the time and patience, fixing the data and code is the better approach to take, but sometimes this isn't always feasible.
Why don't you use LIKE operators (they're appropriate when you have a pattern using % and _):
select * from customers where DateEntered like '%2013' or DateEntered like '%2012'