Thanks to Mike Taylor and Chris and Mark in the Brisbane Mapinfo Office for their assistance - and I believe some rapid responce from the US tech support.


The bad news is that easyloader doesn't translate the integer field types to Oracle well. But it may be that the issue is not in easyloader itself, but rather in the oracle client software. We were using SQL10Net client, and you might get more success from the old 2.3.4.0 client, as evidently the field choice in translation is controlled by the client libraries.

SO I will go with Mike Taylor's solution of creating the tables in Oracle first, and appending the data in mapInfo to those existing tables. I will resist the urge to write a script from Mapbasic to do this - although it shouldn't be that hard). Perhaps if easyloader were to use this approach, it wouldn't not have the issues it does (note to those who are currently assessing the neccessary options for Easyloader for version 8.0.

The problem is that Integer data converted from MapInfo become NUMBERS in Oracle, which in version 7.0 of Pro then gets opened up as decimal(2,0) - which is useluess for numbers over 100. Version 7.5 evidently fixed this bug and it opens them up as floats (a bug fix?), but this is useless when the integers are actually used as primary keys in MapInfo. This may be something out of the control of MapInfo, and is embedded in the mapping of the translation types in the client controls.

I have in the past used a CINT(field) in the select string in the past to force integer or date types when connecting to databases using ODBC, but unfortunately there is no Oracle equivalent that I am aware.

SO the only workaround I can see is to use Number (13) field types in oracle when I create the tables, which then translate to Decimal(13,0) in MapInfo. This will at least maintain the integrity of the number and give me a chance of using this field as a primary key between tables.

I actually think that Easyloader worked fine in 2000 when I last trialled it into Oracle and Version 5 or whatever we were up to then, but I am not sure.

Anyway,
Thanks for the help.

r


On Wed, 4 May 2005 15:48:32 +1000 (EST), <[EMAIL PROTECTED]> wrote:

Hi all,

I am trying to get an Oracle installation going and we've got it going to
some degree but there are some issues with field types.

When I uploaded tables that had integer field types, the Integer fields
became NUMBER s in Oracle, and then when you open the tables up in
MapInfo, the NUMBER field became Decimals, sometimes too small to hold the
data correctly (eg. Decimal (2,0) even where there were numbers > 100 in
thd database. If you opended the tables up live, these fields became
Decimal(2,-127).


I am using MapInfo 7.0 and Oracle 10g.

My question has 2 parts: whether there is a way you can control the field
type that an integer becomes in Oracle using Easyloader. If this can't be
done, then there is an option of changing these in Oracle, but it is a
drama as you can't just change a field type, but have to recreate the
table, copy the data, drop the old one and recreate a new one (a pain with
spatial indices).


And (2) Is there a way that you can make MapInfo open Oracle tables with
integer field types as Integers?

Thanks

Robert.


--------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 16350





-- ________________________________________________

Robert Crossley

Agtrix P/L
9 Short St
PO Box 63
New Brighton 2483
Far Southern Queensland
AUSTRALIA

153.549004 E 28.517344 S

P: 02 6680 1309
F: 02 6680 5214
M: 0419 718 642
E: [EMAIL PROTECTED]
W: www.agtrix.com
W: www.wotzhere.com
skype: robertcrossley

---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 16379



Reply via email to