DateTime Metadata Mismatch Warnings

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

DateTime Metadata Mismatch Warnings

Post by GloriaRR »

I work on a project that maintains a set of tables in SQL Server. We then make these tables available on other database platforms as needed. I am currently working on a project to put a copy of the tables on Informix.

Since the Informix tables have the same structure as the SQL Server tables, I wanted to reuse existing server jobs that extract data using an ODBC Stage from the SQL Server tables. I did this by setting the jobs to allow multiple instances, and used parameters to identify the data source, user ID, and password.

This worked fine except for the DateTime columns. Apparently SQL Server defines its DateTime with a length of 23 and a scale of 3, while Informix defines its DateTime with a length of 25 and a scale of 5. Thus the exact jobs run without warnings when the parameters point it to SQL Server. But when the parameters point it to Informix, it gets metadata mismatch warnings for all datetime fields.

Is there any way to suppress these metadata warnings or to somehow customize the column definitions in the ODBC stage so I can reuse the job without the warnings?
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Perhaps treat them as varchars? Meaning, is there some way generic enough so that handling them as strings would work in both databases? :?
-craig

"You can never have too many knives" -- Logan Nine Fingers
GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

Post by GloriaRR »

Your suggestion worked for the extract. In the ODBC stage I cast the datetime columns as varchar(26) in the Derivation field, changed the column length to 26, and removed the scale. When the job runs against either Informix or SQL Server it does not get the metadata error.

But I have the same problem on the other end of my set of jobs when I use an ODBC stage to write to either the SQL Server table or the Informix table (parameterized just like the extract step). This time I don't think something generic will work, since the database is expecting a datetime.

So I'm back to my original question, except this time it's for a load job instead of an extract job. Is there any way to suppress these metadata warnings or to somehow customize the column definitions in the ODBC stage so I can reuse the job without the warnings?
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Sheesh, no other takers? :roll: Ok, I'll try again.

What are the two formats expected by SQL Server and Informix? How different are they? Perhaps another generic attempt using varchar and a custom routine that formats the date appropriately? Pass in the date string and database type, pass back out what is needed.

Or does the SQL itself need to change for each database? Tell us what is needed and we'll see about getting you there.
-craig

"You can never have too many knives" -- Logan Nine Fingers
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

I'd say go for Craig's solution. Make the date field as varchar. Pass in a parameter as DBType. Check for parameter value inside the job and in a stage variable switch betweent he two formats.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

Post by GloriaRR »

I'm not sure how to accomplish what either of you are recommending. So here's a little more detail of what exactly I'm doing.

The job consists of a sequential file stage containing the records to be loaded into the database and an ODBC stage that connects to the appropriate database based on a parameter. In the ODBC stage I have to provide the column names and types for the table being loaded. The table name, column names, and column types are the same in both databases.

The only difference is with the datetime columns.
- In SQL Server they are simply defined as "datetime". In the DataStage ODBC Stage, this becomes a column of type "Timestamp" with a length of 23 and a scale of 3. (Anything else gives the metadata mismatch error.)
- In Informix they are defined as "datetime year to fraction(3)". In the DataStage ODBC Stage, this becomes a column of type "Timestamp" with a length of 25 and a scale of 5. (Anything else gives the metadata mismatch error.) I tried changing the Informix definition to "datetime year to fraction(1)", but Informix length and scale did not change, and I lost two decimal places in the column's value.

When I execute the job to load to Informix with the ODBC definition that works for SQL Server, I receive the following warnings:

"DSD.BCIOpenR results of SQLColAttributes(creation_date) gave MetaData mismatch
MetaData mismatch on COLUMN.SCALE Expected = 3 Actual = 5" and

"DSD.BCIOpenR results of SQLColAttributes(creation_date) gave MetaData mismatch
COLUMN.PRECISION Expected = 23 Actual = 25"


In the ODBC stage I can't use a parameter for the column length and scale. If I could, I'd be all set. But I don't think I can just use varchar for the type, since that wouldn't match the database either and would give the same metadata mismatch error.

What am I missing?
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

Did you try executing with datatype as varchar and length say 26 and no scale on both the databases. You need to find what length of varchar datatype will work for both databases. If you can find that, you will be all set.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

Post by GloriaRR »

I've tried that, and there's still a warning.

I can change the type to varchar with a length of 26 and no scale. Then I get following warning:
"DSD.BCIOpenR results of SQLColAttributes(creation_date) gave MetaData mismatch
MetaData mismatch on COLUMN.SCALE Expected = 0 Actual = 5"

I can change the type to varchar with a length of 26 and a scale of 5, which works for Informix, but I get the following warning for SQL Server:
"DSD.BCIOpenR results of SQLColAttributes(creation_date) gave MetaData mismatch
MetaData mismatch on COLUMN.SCALE Expected = 5 Actual = 3"

So I really didn't accomplish anything.
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

A little bit off topic but tell me this, What does this date column represent? Is that the current timestamp ? Or a different datetime value needed from the source?
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

Post by GloriaRR »

The creation_date was just one example. There are several datetime fields in the tables we maintain. There are creation dates, last change dates, active dates, inactive dates, etc. Sometimes the time part of it is not important, but other times it is important.

I also have the requirement that since the tables in Informix amount to a copy of the SQL Server tables, we need to keep the data in Informix exactly the same as it was in SQL Server. I could eliminate my frustration if I just created two separate jobs, and didn't try to reuse existing jobs, but I thought I'd give it a try.
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

GloriaRR wrote:I could eliminate my frustration if I just created two separate jobs, and didn't try to reuse existing jobs, but I thought I'd give it a try.

I think that could be your only way. I do not see how you can re-use the same job with different meta data for different targets. If the metadata was identical then you were all set, but unfortunately thats not the case. Maybe someone here can open other doors, untill then, start building your jobs.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
GloriaRR
Participant
Posts: 8
Joined: Mon Mar 29, 2004 10:49 am

Post by GloriaRR »

After additional searching, I have found the problem to be with the DataDirect Informix driver that maps all Informix data types of "Datetime year to fraction(x)" as fraction (5), regardless of how the data is defined in Informix. In my Informix tables, I have "Datatime year to fraction(3)" since this matches what I have in SQL Server, but that obviously doesn't match the metadata in the Informix driver.

So, to make a long story short, I was able to reuse the extract job by casting the datetime columns as varchar. Unfortunately I'm not able to reuse the load job because there's no way to cast the column types for an insert/update statement, and changing the type to varchar still gives a metadata mismatch on the scale portion.

But at least I have the solution for the front half. Thanks for your help!
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

Thats a good sign. Atleast you got half of it working. The data type mismatches are very critical to databases. I was hoping it would work as varchar but apparantly it did not.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
ray.wurlod
Participant
Posts: 54595
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

For the load part, can you not simply append sufficient fractional seconds digits? Something like:

Code: Select all

Field(InLink.TheTime, ':", 1, 2) : ":" : Fmt(Field(InLink.TheTime, ":", 3, 1), "8R5##.#####")
(This form will work with both times and timestamps.)

Or, if you have only whole seconds:

Code: Select all

InLink.TheTime : ".00000"

Or, if you have exactly three fractional seconds digits:

Code: Select all

InLink.TheTime : "00"

Or find a better ODBC driver.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

The issue remains with the metadata, rather than data itself. Both hold different scales which is causing the problem.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
Post Reply