Unanswered: Exporting to comma delim text file, format of numbers changing
Hi - in exporting to a comma delimited text file from access via vba, my numbers are re-formatting. How do I ensure that the ones without decimals, remain without decimals? I've set all the formats in the tables and the forms and they appear alright there, but once exported they change format....
Within the database it's fine, but once it's in the text file it changes to the long date format. I've tried going into the 'spec', but I can't even find anywhere to edit it even under the 'Advanced' tab.
I always format the date as mmm so it wrights the word most progam can pick up the word
what the differance 01/05 05/01 is it jan or may (new zealand here dd/mm/yyy format )
i have found that msaccesss has a guest on what it think it should be
so i always format my dates to dd mmm yyyy format when exporting
hope this help
See clear as mud
the aim is store once, not store multiple times
Remember... Optimize 'til you die!
Progaming environment: Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010 VB based on my own environment: vb6 sp5 ASP based on my own environment: 5.6 VB-NET based on my own environment started 2007 SQL-2005 based on my own environment started 2008 MYLE YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.
DTPicker4DateToday was already a field name - maybe that's why it's not working. Should I just delete both field names and then start again without using a date picker but just making the user type in the date (I really would prefer a date picker though)... what do you suggest?
Myle - I can't do what you suggested because part of the requirements spec is that the text file should contain dates in the format dd/mm/yyyy, but thanks anyway.
see posting #5 frm tcace
tcace already pointed out to you that you are formatting a date/time value as a date and stroring it back as a date time/value
generate your export using a query, do your formatting in that query
forcing a numeric month on a date value is always prone to problems especially if the exported file is going to computer system.
as an alternative use a file export specification: set the date format in the export specification as required. I think yu cna also set numeric fields defining the number of decimals
Concur with myle dd mmm yyyy, or mmm dd yyyy, or yyyy mmm dd etc.. is far safer - text imports can nearly always handle those safely. Unless of course its going to a predetermined file format when you have no choice. The number of times I've sent exports of data to client computers which think they are America rather than the true date zone and had the imports throw an exception as it read 12/22/2005 as month 22, or far worse where 01/12/2005 is interpreted as 12th january, rather than 1st Dec
Nothing was working but I finally got round it by simply changing the format in the table to 'short date' and it worked . I take your point about the formatting i.e. 'mmm' and will bear it in mind for other projects, but the client for this one has insisted they want it in the dd/mm/yyyy format, but I will definitely bear all your comments in mind. Thanks again.