OK, this should be really simple so it's baffling that it isn't. I'm doing a very basic copy of data from Excel and paste append into an Access database. So why are values and sometimes entire records vanishing?
Details: I'm using Access 2016 in Windows 7 importing data from Excel workbooks supplied by a subcontracting lab into our database. The lab doesn't always use exactly the same format to report their results, so importing directly from Excel becomes unreliable. I would love to use an append query but they work poorly if the data is one column to the right of where it ought to be.
Instead I have a messy little temporary table with no primary key and five fields, all short text and some VBA to validate, tidy, and properly import it. Copy from Excel, Paste Append into Access and... WTF?!? Fields paste in with null values. Occasionally records vanish. No Paste Errors Table, no error message. Just data gone!
There is a pattern to the missing data. I have 5 fields, the first two are always text, the next two are always numeric, and the last field is sometimes numeric and sometimes text. Unsurprisingly the problem is in this last field. If all of the data in the 5th field is numeric then everything works fine. Similarly if all the data n field 5 is text. It's when there is a mix of numeric data in some records and text in others that data vanishes and it's the text that's pasting in as nulls. If the first record contains text in field 5 it goes missing altogether.
Why?!? This should be the easy part! Ironically, the VBA works fine.
Fixes that I have tried:
Converting the Excel workbook to CSV to avoid hidden formatting or similarly unhelpful problems on the Excel end.
Building a fresh database to avoid inherited gremlins. A database consisting of nothing more than the single table of five short text fields experiences the same issues.
Stripping potential trouble characters. While not a special or reserved character, the "<2" had me concerned, but "bob" fails to import just as mysteriously.
Changing fields to long text, making them required, or setting primary keys. The text values still paste in as nulls and, if it's set to "Required", shunts the entire record to the Paste Errors table.
Importing the records one at a time. This actually does work in that the data pastes correctly but is less than desirable when working with 1000 plus records. It does suggest that it isn't the structure of the database that's the issue.
Any help would be greatly appreciated.
I finally found the answer. It's a little known bug somewhere in Excel, Access, or the clipboard and appears to have been around since at least 2007. Records with both text and numeric data in a field will lose the text data upon paste append to a text field.
1, 2, 3, 4
5, 6, 7, apple
8, 9, 10, 11
12, 13, 14, berry
15, 16, 17, 18
Paste Appends from Excel to Access as
1, 2, 3, 4
5, 6, 7
8, 9, 10, 11
12, 13, 14
15, 16, 17, 18
The "solution" is to close Excel before you Paste Append. This dark ritual will cause the data to append correctly. I have no idea why this is but have confirmed it with my own database.
Related
I have a table LABELS with columns CODE(short text), VALUE(short text) and DESCRIPTION(long text).
I also have a table LABELS_HISTORY with the same columns.
I created and After Delete macro on LABELS, which creates a new record in LABELS_HISTORY with the values of the deleted record from LABELS.
If I only use it for CODE and VALUE (which are short text), it works fine. But if i try to also copy the DESCRIPTION, it doesn't work (no error, just doesn't create a record in LABELS_HISTORY).
This is how the macro looks like: ( i can't embed images - newbie)
https://i.stack.imgur.com/igKlh.png
If you don't want to open the link:
Labels: After Delete:
Create a Record In LABELS_HISTORY
SetField
Name Description
Value = [Old].[CODE]
it works fine with fields that are short text. Only problem is with Long Text.
Access 2016
Long text values are not available through [Old].. There is no work-around as far as I know.
This does generate an error. In your USysApplicationLog table, an error should be logged, that has the following description:
The '[Old].[DESCRIPTION]' value is not available because the field is of type memo, rich text, hyperlink, or OLE Object.
(memo is the old name for Long Text fields, thus these are not available).
You can also see this behaviour in MS SQL Server, where previous values of fields of the type Text and NText are also not available in triggers.
A piece of advice: always log the Current value in your change tables, not the Previous one. That way, you always have a full history of every record, and you don't run into trouble with these things.
I have imported a csv file from MySQL, documenting part numbers and descriptions. Some of these part numbers have values like 1234567890987654321, which is then shortened by excel to 1.23e18. Problem is, I cannot query a part with this formatted data.
Now I cannot feasibly go through every cell as there are just over 28000 of them. I have converted the row to text however this does not change the data in the cell.
The closest thing I have to a solution is deleting the cells and then undo-ing, which gets the number in a textual format but then gives me a 'number in text field' error.
Also some parts have part numbers like 12E345 which is then changed to 1200000000000000000000000000000000000000000000- you get the picture.
Very annoying...
I would like a batch process to change all the values to text format, thanks in advance.
Instead of just opening the CSV in Excel, import it with Data -> External Sources -> From Text.
You will have to first pick basic things like "delimited" format, whether first row contains headers, separator etc.
In the third part of the "Text Import wizard", you can pick data type of each column - picking Text for your columns will probably solve the problem.
I have a spreadsheet which is a report from an external supplier. The date columns are formatted completely different from how a little acccess database works, so i decided to record a macro in excel to alter the 3 columns to a dd/mm/yyyy format (im uk btw). This all works great and the column isshowing as above and is listed as a 'DATE' format also.
Now i use access to link to this excel sheet by means of a linked table, but i noticed that any queries that i wish to filter on those fields in the form of a where clause, it does not pull in the expected result IE it pulls all dates and not the ones between what i asked for in the queryalmost as if it is not recognizing them as dates see the where clause below
WHERE LatestGamma.ConfirmedPortingDate Between [Please Provide 1st Date (dd/mm/yyyy)] And [Please Provide 2nd Date (dd/mm/yyyy)];
I also tested it by using actual dates in the between cluase and it still appears to ignore it.
When i look at the properties of linked table for those columns, it shows that the fields are: dd/mm/yyyy;# but are showing as text??
When i look at the excel macro to see what code the macro used for changing the date format of the columns i see:
Columns("F:H").Select
Selection.NumberFormat = "dd/mm/yyyy;#"
I have another excel sheet that is used as a linked table and date columns are working fine and show as date/time and not Text. Its almost as if excel is putting some meta data into the columns that is making access interprate them as text (even though they are formatted as date)
Im stuck her some help/advise would be great
Its hard to tell without looking at the file, but it seems the main culprit is the excel macro which is not converting the string to date format correctly. You can try converting string into date format by using something like this in excel VBA
Sub convert()
Dim str1 As String
str1 = Range("f6").Value
startdate = CDate(str1)
End Sub
You probably will have to loop thru all the cells to convert the string (text) into date format.
Sorted it in the end. It was more or less what i was thinking IE the column although was showing as a Date type seemed to be storing it as some sort of text. Anyway the way round it was to use the text to columns button and force it to be a date in DMY format.
Once i had tried it i then recorded the actions as a macro and copied the resulting code to my main macro at the end, bingo ! Access now sees it as a date and not text.
Not sure if it is a bug or not but Excel can be a real pain sometimes especially with phone numbers, having to store them as a data type text to keep the leading zero and then immediately converting them to General to allow vlookups etc. I guess that is the same sort of thinkg going on above showing as a date yet actually having like a suedo text meta thing going on...
I am using Office 2003
On Access, I export values from a form into a .xls, after that using mail merge on word I import the data to be displayed on the file. Data such as dates and strings are displayed correctly.
In Access theres the value 9,916.12 wich is exported to the .xls as 'price' that contains 9,916.12, both values match keeping the same format, but when mail merge kicks in the value displayed on the document becomes 9916,1200000000008.
I am lost as to what is causing that. The field that is being exported contains only 2 decimals, it displays on excel as a value with only 2 decimals yet when word reads it, it adds random decimals to it. If I manually alter the value on excel the error persists, so does it if I choose a different record to be exported.
Any tips on how to solve the problem?
See this Microsoft Answers discussion and this in-depth description on how to use a merge field such as {Mergefield NumberFieldName \# ",0.00"} to work around the issue. It's been awhile since I had to do mail merges, especially with Word 2003, but I think that should do it.
An Access DB imports a fixed width text file; one column is mostly dates.
When the date is not available, the file's creator actually uses the string "Null"
Access puts the row in the table with that field actually null.
But, when the files started coming with different field widths, I copied the DB, tweaked the starting/width values in the input spec, and imported. NOW, all the rows with null get logging in (table)_import_errors as an error converting text to date.
I have found no setting (not that I changed any) to explain it. One difference is that although both DBs are in Access 2000 format, the original is on a machine that still has Access 2000, while the new one is being handled by Access 2003.
Is that a behavior change in the Access version? Is pre-processing the file the only solution?
Thanks, David. That's what I would have done (except for the Excel part) if it had not fixed itself. I posted that, but apparently someone didn't like the public admission that Access has bugs.
The only thing that changed was that two other columns in the fixed width plain text input was wider. Yet Access "decided" to discard the whole row instead of just the date field for three consecutive attempts. The fourth time, it still reported it as an error but imported the rest of the row.
So, when Access misbehaves for no good reason, try again a time or two, then try explicitly coding the conversion from text.
Two possibilities:
Use a buffer field or buffer table that imports the date field into a text field. Then you can process that into the appropriate values in the final destination field.
Use a SQL import instead of DoCmd.TransferText. What you do in that case is use a connect string in the FROM clause so you can then process the date field in your SELECT:
SELECT Sheet1.FirstField, Replace(Sheet2.DateField, "NULL", Null) As DateField
FROM Sheet1 IN 'C:\Import\Spreadsheet.xls'[Excel 5.0;HDR=YES;IMEX=1;];
Convert that into an INSERT query and you're golden.