DoCmd.TransferText truncating date field

[Jimjam]

Hello. I have a subroutine that exports the tabular results of a query to a csv file using..

DoCmd.TransferText acExportDelim, , sQry, sPath, True

Very straight forward but it truncates the invoice date column clipping of the right most digit. ie what should read in the outputted file...
,"3/1/2017",
ends up as
,"3/1/201",

Running the query in access looks just fine.
I've added a CDate(dteField) to force it to be treated as a date but get the same result (notably still in ""s ). The source query is in aggregate with the date field as a groupby. Not sure if that has anything to do with it.

Seems like a bug in the TransferText command. At a loss.

 

[Minty]

Are you using Format() anywhere on the date field - that will convert it to a string.

 

[Jimjam]

Hi. No format function. The source query to this query to be outputted determines the value of this field using DateSerial to land on the last day of the month.
Even if this were text I do not think it a good idea that the transferText function lops off even a single character of any format. Still perplexed by this.

 

[The_Doc_Man]

Although you defaulted the schema, there is a chance that you have a "leftover" to consider. If you have ever used the import/export manager to generate a specification for some other operation, you MIGHT have a leftover schema.ini file in the same folder as your database file. Check for that possibility. If you have one, then it might be something in that schema that is truncating the output.

Solution, if true, is rename the extant schema file to some other (specific) name. You can then give that new name next time you want to use that schema, but there will be no phantom specification in the way for this operation.

If that ain't it, you've got me on that one.

 

[Jimjam]

Hi. I figured I should round back and provide an update.

There was no defaulted schema ini file in the directory.

I opted to just create a function from scratch that punts the recordset to a file.
Worked for my purposes and moved on. The issue with the MS built-in function remains a mystery.

Regardless - Thank you both for the input.