Variabler size mismatch

[Cheek Bob]

Walter,

I don't think that it is an error with the way date could be formatted in
Oracle because you would get an invalid date error of some type.  This seems
more on the byte/bit level.  An Oracle date is an 8 BYTE field (64 bit).
Which is why the SIZE 8 sounds right to me.  Make sure the date inside the
portable file matches.  Compare it's definition the subfile dictionary to
the actual in one in the portable subfile.   I asked around here and one
person responded:

They have had lots of problems with subfiles.  (Usually indexed subfiles,
though -- not portable).  If portable subfiles are using XBASE, which is the
NT index file handler, then they suspected that the issue is that XBASE
doesn't support the element type that you are writing to in the subfile. 

Here is a similar problem that they had with indexed subfiles.  When writing
an INT*4 field to an indexed subfile, then XBASE brings the field in as a
FLOAT, since it does not support INT fields.

Bob Cheek
Visibility Inc.
http://www.visibility.com

	-----Original Message-----
	From:	Walter Lucas III [SMTP:whl3@nwths.com]
	Sent:	Monday, August 16, 1999 6:02 PM
	To:	Maillist Cognos
	Subject:	Re: Variabler size mismatch

	Thanks, Roger.  I'll tinker some more.

	Walter
	-----Original Message-----
	From: Marcinik, Roger <MARCINIR@pgocm3.ksc.nasa.gov>
	To: 'Walter Lucas III' <whl3@nwths.com>
	Cc: 'Roger Marcinik' <rogerm@compuserve.com>
	Date: Monday, August 16, 1999 12:42 PM
	Subject: RE: Variabler size mismatch



	believe this is an Oracle thing. Found this in Oracle 8
documentation:


	-----------------------------------------------------------


	DATE Datatype

	BM_800The DATE datatype stores point-in-time values (dates and
times) in a
	table. The DATE datatype stores the year (including the century),
the month,
	the day, the hours, the minutes, and the seconds (after midnight).

	BM_2807Oracle can store dates in the Julian era, ranging from
January 1,
	4712 BCE through December 31, 4712 CE (Common Era). Unless BCE ('BC'
in the
	format mask) is specifically used, CE date entries are the default.

	BM_802Oracle uses its own internal format to store dates. Date data
is
	stored in fixed-length fields of seven bytes each, corresponding to
century,
	year, month, day, hour, minute, and second.

	BM_804For input and output of dates, the standard Oracle default
date format
	is DD-MON-YY, as below:

	BM_806'13-NOV-92'
	BM_5140
	BM_814You can change this default date format for an instance with
the
	parameter NLS_DATE_FORMAT. You can also change it during a user
session with
	the ALTER SESSION statement. To enter dates that are not in standard
Oracle
	date format, use the TO_DATE function with a format mask:

	BM_816TO_DATE ('November 13, 1992', 'MONTH DD, YYYY')
	BM_5141
	BM_5142

	_____

	BM_5145Note:

	BM_5146
	If you use the standard date format DD-MON-YY, YY gives the year in
the 20th
	century (for example, 31-DEC-92 is December 31, 1992). If you want
to
	indicate years in any century other than the 20th century, use a
different
	format mask, as shown above.


	_____



	BM_822Oracle stores time in 24-hour format - HH:MI:SS. By default,
the time
	in a date field is 00:00:00 A.M. (midnight) if no time portion is
entered.
	In a time-only entry, the date portion defaults to the first day of
the
	current month. To enter the time portion of a date, use the TO_DATE
function
	with a format mask indicating the time portion, as in

	BM_824INSERT INTO birthdays (bname, bday) VALUES

	BM_5164    ('ANDY',TO_DATE('13-AUG-66 12:56 A.M.','DD-MON-YY HH:MI
A.M.')

	-----Original Message-----
	From: Walter Lucas III [mailto:whl3@nwths.com]
	Sent: Monday, August 16, 1999 4:44 PM
	To: Maillist Cognos
	Subject: Variabler size mismatch


	Hey guys,

	This is Walter at NWTHS again. We now have Axiant running, the
Oracle
	database in place and accessed, and are converting everything we
can. Life
	is good.

	"And now for something completely different..."

	We've been pulling data off an HP mainframe in the form of portable
subfiles
	and loaded our Oracle databases. This was working well until I
started
	loading dates.

	The error I get is "VARIABLE SIZE MISMATCH." It then list the column
and
	the name of my field. Originally, I loaded the fields as strictly
date
	using the default on the mainframe. Then I built new fields with the
	CENTURY INCLUDED option and passed those.

	When neither of these worked, I handled the field builds on the
Axiant size
	first setting the value to a zoned number, then a date, then a date
with the
	century included. All had the same result.

	I've read all the help and books on both systems. I don't know if
this is a
	Cognos or Oracle issue. The data fields in Axiant are sized as 8.
The
	Oracle database shows the field to be a date field, but gives no
indication
	of size.

	Have any of you seen this error? And if you have what did you have
to do to
	fix it? More importantly, where did you find the information you
needed to
	fix it? I'm having trouble finding in-depth documentation on a
variety of
	problems.


	Thank you,
	Walter Lucas
	Applications programmer
	Northwest Texas Hospitals
	Amarillo, Texas



	= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = =
	Subscribe: "subscribe powerh-l" in message body to
majordomo@lists.swau.edu
	Unsubscribe: "unsubscribe powerh-l" in message to
majordomo@lists.swau.edu
	powerh-l@lists.swau.edu is gatewayed one-way to
bit.listserv.powerh-l
	This list is closed, thus to post to the list, you must be a
subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.