Topic
  • 6 replies
  • Latest Post - ‏2012-05-15T19:49:48Z by GregWathen
GregWathen
GregWathen
13 Posts

Pinned topic Does the IDMT extract large LOBs at all?

‏2012-05-03T21:43:48Z |
I still have not gotten any response to my question posted over a week ago. Can anyone tell me if they have been able to extract large (>32k) LOB columns with IDMT, or am I just wasting my time?
Updated on 2012-05-15T19:49:48Z at 2012-05-15T19:49:48Z by GregWathen
  • SystemAdmin
    SystemAdmin
    708 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-03T21:45:49Z  
    What is the issue you are facing with LOBS?

    IDMT extracts all sizes of LOBS.
  • GregWathen
    GregWathen
    13 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-04T17:45:49Z  
    What is the issue you are facing with LOBS?

    IDMT extracts all sizes of LOBS.
    As I posted 2 threads down, I am trying to extract data from a MySQL database that has TEXT columns that are up to 64K. The extract places the data from these in the same file as the other columns, so the DB2 load truncates those columns since it cannot handle anything over 32K without using the LOBSINFILE process.

    I have tried editing the datamap.properties and that does cause the resulting DB2 DDL to define those columns as CLOB rather than the default LONG VARCHAR, but that doesn't help.

    I even altered the MySQL table columns from TEXT to BLOB, but the unload still extracts the data all into one file rather than producing separate LOB files.
  • GregWathen
    GregWathen
    13 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-11T18:12:40Z  
    As I posted 2 threads down, I am trying to extract data from a MySQL database that has TEXT columns that are up to 64K. The extract places the data from these in the same file as the other columns, so the DB2 load truncates those columns since it cannot handle anything over 32K without using the LOBSINFILE process.

    I have tried editing the datamap.properties and that does cause the resulting DB2 DDL to define those columns as CLOB rather than the default LONG VARCHAR, but that doesn't help.

    I even altered the MySQL table columns from TEXT to BLOB, but the unload still extracts the data all into one file rather than producing separate LOB files.
    Can I get some help here? It has been over 3 weeks since I originally posted this question and I still have gotten no response besides another question.
  • bluey01
    bluey01
    6 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-15T12:32:13Z  
    Can I get some help here? It has been over 3 weeks since I originally posted this question and I still have gotten no response besides another question.
    I too had some problems with BLOBs and I suspect there is not much experience on this forum with CLOBS & BLOBS as I had a similar (lack) of response.

    Anyway - I had some tables with CLOBS & BLOBS and IDMT didn't handle them at all well, so what I ended up using IDMT to do all the data tables and then used data studio to manually extract the BLOB tables and then to load them into the target database - not elegant - but it worked...
  • SystemAdmin
    SystemAdmin
    708 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-15T12:54:28Z  
    The tool has been used several times to extracts LOBS from MySQL and it places them in a separate file and the original file has information about the file name, offset and length. I am sure that you are using the latest version which is 2.00-b2116.

    Post a sample MySQL table ddl and I will check.
  • GregWathen
    GregWathen
    13 Posts

    Re: Does the IDMT extract large LOBs at all?

    ‏2012-05-15T19:49:48Z  
    The tool has been used several times to extracts LOBS from MySQL and it places them in a separate file and the original file has information about the file name, offset and length. I am sure that you are using the latest version which is 2.00-b2116.

    Post a sample MySQL table ddl and I will check.
    This is the ddl of the MySQL table:

    CREATE TABLE A (
    C1 char(22) NOT NULL,
    C2 varchar(64) DEFAULT NULL,
    C3 text NOT NULL,
    C4 text NOT NULL,
    C5 int(11) NOT NULL,
    C6 date DEFAULT NULL,
    C7 varchar(32) DEFAULT NULL,
    PRIMARY KEY (C1)
    ) --ENGINE=ndbcluster DEFAULT CHARSET=latin1

    As I said in one of my previous posts, I tried altering the MySQL table from text to BLOB datatypes for the two text columns. I also changed the datamap.properties file and tried several different combinations of the varcharLimit and numRowsToCheck variables.

    No matter what I do, all of the output goes into one file, schema_A.txt.