All records are numbers, although you are right in that it seems that some do not have leading zeros.
One that I can't seem to get around is the dates, which are currently recorded as a number as in MapInfo (YYYYMMDD). When these are forced to be dates, they work fine as dates in MapInfo, but of course the text driver wants to force them to be numbers, and I can't seem to override it.
I think that it is likely that I will go down a DBMS route, changing the type of the field using a conversion function. These generally fail if you throw a null field at them, so should be one fun SQL statement. The numbertodate function should be a hoot to.
R
On Tue, 28 Oct 2003 21:47:51 +1100, Martin Higham <[EMAIL PROTECTED]> wrote:
Presumably your problem is numeric columns being interpreted by MapInfo as
character ? In that case, you need to ensure that all fields in numeric
columns in the text file have numbers in them - including zeroes instead of
spaces.
Essentially you'll need to either amend the text file format or create an
intermediate step which either reformats the text file, or generates the tab
file programatically. Sounds like a bit of a hassle.
Best Regards,
Martin Higham Avantra Geosystems
ph (61 3) 8504 0428 0425-730-428 fx (61 3) 9596 7997 www.avantra.com.au
-----Original Message----- From: Robert Crossley [mailto:[EMAIL PROTECTED] Sent: Tuesday, 28 October 2003 20:24 To: MapInfo List Subject: MI-L Why does MI restructure text Files?
Hi all,
Have come across an annoying feature of MI when opening text files, or perhaps it is a bug?
When you open a text file, MapInfo creates a tab file for it as it should. Unfortunately, the field types assigned to the various fields seem a bit random. You can fix this by editing the tab file and specifying the field types in the table definition. So far so good.
But if you replace the text file, MapInfo rewrites the tab file again, and gets the field wrong again. Am not sure of the trigger, but thought perhaps it is the time stamps on the tab and text files? I assume that it does this so as not to corrupt index files.
Not sure what to do about this (I don't have to have indices), as I want to replace this text file frequently during the day - and not have to edit the tab files each time. I could write a routine that copies the tab file before it replaces the text file, but really....
Went down the path of setting up a linked DBMS table using the text file drivers, but the field guesses were just as bad, and I could not see anywhere to specify the field type either. This would actually be the preferred path as I could have indices on the table.
One answer seems to be to force it to define a column as a type such as a
integer or a date by formatting the column in the SQL statement (eg.
CINT()). The syntax will thus be based on the ODBC driver chosen, Which
means that I can't use the NumberToDate function, and need to do some
parsing...., and include some IFF and IsNumeric statements to weed out
nulls that cause errors when thrown at conversion functions....
Am willing to go down that path, but can't help but think that perhaps i am missing something?
r
--
Robert Crossley
Agtrix P/L 9 Short St New Brighton 2483 Far Southern Queensland AUSTRALIA
153.549004 E 28.517344 S
P: 02 6680 1309 F: New Connection M: 0419 718 642 E: [EMAIL PROTECTED] W: www.agtrix.com W: www.wotzhere.com
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 8899
--
Robert Crossley Agtrix P/L 9 Short St New Brighton 2483 Far Southern Queensland AUSTRALIA
153.549004 E 28.517344 S
P: 02 6680 1309 F: New Connection M: 0419 718 642 E: [EMAIL PROTECTED] W: www.agtrix.com W: www.wotzhere.com
--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 8907
