I'm embarrassed to even ask this because this should be a no brainer exercise but I cannot seem to get ascii import to work. Here is a sample of the txt file I am trying to import and it fails on the first line and says the time format I am using is in error.

6/22/2011 10:42 AM 45.95 45.98 45.94 45.98 50570
6/22/2011 10:43 AM 45.98 45.98 45.95 45.96 110513
6/22/2011 10:44 AM 45.96 45.96 45.94 45.95 96181
6/22/2011 10:45 AM 45.95 45.96 45.93 45.94 174181
6/22/2011 10:46 AM 45.94 45.95 45.92 45.93 347382
6/22/2011 10:47 AM 45.92 45.94 45.92 45.94 104494
6/22/2011 10:48 AM 45.94 45.96 45.94 45.96 86585

I am importing it as 1 minute data. I added the time column to the import list using the add button in ascii import and using space delimiter.

I have used many different ascii imports over the years and this is the first that has stumped me.

As an exercise I also right clicked a chart, copied data to clipboard and then pasted it in a spreadsheet. Then saved the spreadsheet to a csv file and tried to import it using data manager ascii import but could not get any of the formats to work. They all failed on the date format. This seems like a round trip that should be a no brainer.

So, what time format did you enter?

I read the microsoft date/time format as pointed to by the WLP help on formats.

I tried several formats but my best interpretation of the possibly correct forms are

hh:mm tt
h:m tt
hh:mm t

Looks like that "HH:mm tt" should work. If it doesn't, try "H:mm tt".

Thanks. Tried both and they both failed saying 10:42 not a valid time format.

My understanding of H is that it means a 24 hour clock and precludes the need for the tt symbol for AM/PM.

Still no joy in ascii import land. Like I said seems to be a no brainer but cannot get it to work.

Now it looks like a bug to me. Please create a support ticket.

Ok. I did get something to work. Taking out the space between the time and AM/PM was a format that worked. In other words

6/22/2011 10:42AM 45.95 45.98 45.94 45.98 50570

and using

h:mmtt
or
hh:mmtt

A support ticket has been submitted referencing this discussion.

Yup, that extra space will be interpreted as a new field. (Providing the exact error message from the ASCII provider would have probably made that immediately clear to us.)

Note that AM/PM is pretty useless information in an ASCII file (information means "change"). Simple exporting to a HHmm format makes for a smaller file footprint and won't result in an ambiguous field if you really want to use spaces for delimiters. Of course, using tab or comma delimiters would have taken care of any ambiguity too.

I guess that this bug might very well be a later addition. A side effect of the build that brought support for the buggy Hmm/Hmmss format in .NET.

I cannot seem to get ascii import to work. Here is a sample of the txt file I am trying to import and it fails on the first line and says the time format I am using is in error.

19/03/2001 0,78 0,78 0,76 0,77 136500 "
"20/03/2001 0,77 0,84 0,77 0,83 117900 "
"21/03/2001 0,84 0,86 0,82 0,84 142200 "
"22/03/2001 0,84 0,84 0,81 0,83 94600 "
"23/03/2001 0,83 0,86 0,81 0,86 212300 "
"26/03/2001 0,86 0,89 0,83 0,85 53100 "
"27/03/2001 0,86 0,91 0,85 0,88 168500 "

If the file actually contains those quotes as you're showing it, then you might have success following this FAQ:

FAQ | Data and Data Providers > ASCII Data > "How do I import an unusual ASCII data file with multiple separators?"

However, I'm not sure if it's going to work out... haven't seen such badly formatted ASCII file before. If you don't succeed, call your data vendor and ask him if it's possible to drop the extra quotes from the feed. If still no go, the only thing left is to strip these quotes with a script in your favorite scripting language.

It's too bad there isn't a space after the first quote mark. If there were, you could add 2 Filler fields in the ASCII format specification so that the quotes would be ignored.

Filler fields, good idea Robert. But with them it becomes possible to specify skipping the 1st line of data. ;)

Of course skipping the first n lines is easy, but my guess is that the missing quote mark was a copy/paste error.

Anyway, this quote thing comes up enough to perhaps make a one-liner change to the ASCII Provider to automatically strip out quotes. afaik, quote marks in ASCII data files serve absolutely no purpose in modern computing... unless someone actually uses them as delimiters, but I've never seen that.

I've seen quotes as delimiters in the past, just once. But an option to strip them makes good sense. I'll enter a new support ticket.