Numeric field converting to scientific notation when importing Excel data to SQL Server with OpenRowset

I wrote a procedure several years ago to importing some accounting data for a client from an Excel spreadsheet into into an SQL Server table.  About a year ago, the files started increasing in size and we modified the procedure which was taking several hours to run and are now using the OpenRowSet functionality of SQL Server to import the data.  

That has been running smoothly until last month (they just stumbled upon the problem) when the Invoice_Num column of the spreadsheet.  The values in this column of the spreadsheet are mostly blank (NULL) and a large chunk of the values are text (leading character is A-Z or has an ' as the leading character).  But some of them do not have a leading character that would distinguish the value as a string.  What has started happening recently is that SQL Server is converting these numeric values (those above 1.026M) from numeric values to scientific notation, before they are saved into the destination table.

Part of the code I'm using in my stored procedure to import the data into my database follows.  We elected to create a temporary staging table with the same structure as the destination table, and first upload the data into that staging table.  We did this with dynamic SQL so that we could pass the path, filename, and sheetname from Access to SQL Server to perform the upload.

SELECT * INTO #AccountLedger FROM tbl_Acct_Ledger WHERE 0 = 1

/*Import the data into temporary table*/
Set @SQL = 
'INSERT INTO #AccountLedger ([Voucher_no], [Cost_Center], [Cost_Center_Name]
, [Field_No], [Field_Name], [State], [District_No], [District_Name]
, [Acq_Name], [Oper], [Operator_Name], [Purchaser], [Purchaser_Name], [Project]
, [Description], [Account], [Account_Name]
, [Prd], [Amount], [Qty], [Gross_Amount], [Gross_Qty1]
, [Acctg_period], [Activity_period], [Vendor_no]
, [Vendor_Name], [Invoice_Number], [Invoice_Paid_Amt]
, [Name_ID], [Name_1], [Remitter], [Company])
SELECT [Voucher_no], Convert(nvarchar(20),[Cost_Center]), [Cost_Center_Name]
, Convert(nvarchar(3), [Field_No]), [Field_Name], [State], [District_No], [District_Name]
, [Acq_Name], Coalesce([Oper], ''''), [Operator_Name], [Purchaser], [Purchaser_Name], [Project]
, [Description], Convert(nvarchar(25), [Account]), [Account_Name]
, [Prd], [Amount], [Qty], [Gross_Amount], [Gross_Qty1]
, [Acctg_period], [Activity_period], Convert(nvarchar(25), [Vendor_no])
, [Vendor_Name], Convert(nvarchar(50),[Invoice_Number]), [Invoice_Paid_Amt]
, Convert(nvarchar(255), [Name_ID]), [Name_1], [Remitter], convert(Int, [Company])
''EXCEL 12.0 xml;HDR=YES;DATABASE=' + @FilePath + @FileName + ''',
''SELECT * FROM [' + @SheetName + ']'')'


Open in new window

As you can see, the SELECT statement performs an explicit type conversion of the [Invoice_Number] column in the spreadsheet to a nvarchar datatype.

Is there any way to modify this SELECT statement to force SQL Server to recognize this data as a string, rather than a number?
LVL 50
Dale FyeAsked:
Who is Participating?
Scott PletcherConnect With a Mentor Senior DBACommented:
Not really.

The easiest way is to set all the Excel columns to a "Format" of "Text", then do any needed conversions to numeric within SQL itself.
Dale FyeAuthor Commented:

Will simply setting the format of the columns take care of it, or do you need to actually preface the values with an apostrophe?

If simply setting the format to text works, I should be able to do that with a single:

sht.UsedRange.NumberFormat = "@"

statement in the code that checks to make sure all of the required column headings are present.
Scott PletcherSenior DBACommented:
Setting the format to "text" is enough.  You don't have to put in an apostrophe yourself.
Dale FyeAuthor Commented:
Thanks, Scott.

Worked like a charm.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.