Recently I have converted from UDB 7.2 (NT) to UDB 8.1.4 (W2K) and
have noticed a critical error W.R.T. our VB/ADO apps.
If I use the 7.2 client, then everything (except calls to federated
views) works great. If I use the 8.1.4 client, then I cannot send a
null or blank date back to the database (invalid format). I also
cannot null out the value of a field that has contraints on it
because the null get converted to an empty string (supposedly by ADO)
and that is not a valid value in the contraint list.
I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
Has anyone else seen this and is there some kind of a work-around ??
9  2349 
On Thu, 05 Feb 2004 14:41:47 GMT, kurt.wood@NO**@M.state.mn.us (Remove
the obvious for replies) wrote: Recently I have converted from UDB 7.2 (NT) to UDB 8.1.4 (W2K) and
have noticed a critical error W.R.T. our VB/ADO apps.
Interesting scenario for us, because we have a client with a 7.2
server who is experiencing massive memory leaks when trying to connect
with an 8.1.x client...
What version is the server DB2?
If I use the 7.2 client, then everything (except calls to federated
views) works great. If I use the 8.1.4 client, then I cannot send a
null or blank date back to the database (invalid format). I also
cannot null out the value of a field that has contraints on it
because the null get converted to an empty string (supposedly by ADO)
and that is not a valid value in the contraint list.
There is a big difference between NULL and an empty string. ADO is an
ActiveX layer around ODBC, AFAIK. NULLs have been around since
prehistoric (DBMS) times. You need to distinguish between the two.
How are you defining a "NULL" value on the client side? If the
database column has a NOT NULL constraint on a certain field, there is
presumably a good reason for that.
Is it a matter of bind variables? Or are you constructing the SQL
completely as text?
I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
They are probably right.
Has anyone else seen this and is there some kind of a work-around ??
The work-around is not to try to pass a null value to a column which
has a "not null" constraint. Is there a default value defined? If so,
just leave that column out of any INSERT statements.
--
Bob Hairgrove No**********@Home.com
On Thu, 05 Feb 2004 22:11:48 +0100, Bob Hairgrove
<wouldnt_you_like@to_know.com> wrote: On Thu, 05 Feb 2004 14:41:47 GMT, kurt.wood@NO**@M.state.mn.us (Remove
the obvious for replies) wrote:
Recently I have converted from UDB 7.2 (NT) to UDB 8.1.4 (W2K) and
have noticed a critical error W.R.T. our VB/ADO apps.
Interesting scenario for us, because we have a client with a 7.2
server who is experiencing massive memory leaks when trying to connect
with an 8.1.x client...
What version is the server DB2?
We are using DB2 ESE 8.1.4 on a W2K box.
BTW, I am not surprised you are seeing problems going the other way...
If I use the 7.2 client, then everything (except calls to federated
views) works great. If I use the 8.1.4 client, then I cannot send a
null or blank date back to the database (invalid format). I also
cannot null out the value of a field that has contraints on it
because the null get converted to an empty string (supposedly by ADO)
and that is not a valid value in the contraint list.
There is a big difference between NULL and an empty string. ADO is an
ActiveX layer around ODBC, AFAIK. NULLs have been around since
prehistoric (DBMS) times. You need to distinguish between the two.
I have a firm grip on what null is and what an empty string is. In
this , we have a "nullable" field with a list of 4 possible values. If
, on the VB form, we delete the value in the control, then behind the
scenes we trap for an empty string, convert that to a null and try to
pass that to the database. This works fine on a 7.2 client, but with
an 8.1.4 client, our null is "reconverted" to an empty string.How are you defining a "NULL" value on the client side? If the
We define null by setting it to VBNullString (also VBNull and
VBNullChar)database column has a NOT NULL constraint on a certain field, there is
presumably a good reason for that.
Is it a matter of bind variables? Or are you constructing the SQL
completely as text?
ODBC hanldes the low level operations for the ADO calls.
I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
They are probably right.
Maybe, but that would sure show poor QA/QC in allowing an error to
propagate thru 3 complete versions of DB2....
Has anyone else seen this and is there some kind of a work-around ??
The work-around is not to try to pass a null value to a column which
has a "not null" constraint. Is there a default value defined? If so,
just leave that column out of any INSERT statements.
ahhh, yup...
--
Bob Hairgrove
No**********@Home.com
On Thu, 05 Feb 2004 21:28:50 GMT, kurt.wood@NO**@M.state.mn.us (Remove
the obvious for replies) wrote: There is a big difference between NULL and an empty string. ADO is an
ActiveX layer around ODBC, AFAIK. NULLs have been around since
prehistoric (DBMS) times. You need to distinguish between the two.
I have a firm grip on what null is and what an empty string is.
OK. I apologize if I sounded condescending ... I didn't mean to, just
trying to establish a common point of agreement. You might be
surprised to see how many people don't know the difference, especially
when coming from Access or VB.
In this , we have a "nullable" field with a list of 4 possible values. If
on the VB form, we delete the value in the control, then behind the
scenes we trap for an empty string, convert that to a null and try to
pass that to the database. This works fine on a 7.2 client, but with
an 8.1.4 client, our null is "reconverted" to an empty string.
How are you defining a "NULL" value on the client side? If the
We define null by setting it to VBNullString (also VBNull and
VBNullChar)
Is it a matter of bind variables? Or are you constructing the SQL
completely as text?
ODBC hanldes the low level operations for the ADO calls.
Hmmm ... since nothing has changed on the VB/ADO side, I suppose that
it was passing an empty string all along. Only the DB2 client has
changed.
I wonder if there is a setting in the DB2 client or server which would
influence how the database handles empty strings? I believe that with
Oracle, for example, there is a parameter for this. I know because we
had a procedure with a little lookup table and querying for NULL
worked in our test environment, but failed in production because it
was either returning a single space or an empty string.
What about doing the updates through a stored procedure? Or a
BeforeUpdate/BeforeInsert trigger? I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
They are probably right.
Maybe, but that would sure show poor QA/QC in allowing an error to
propagate thru 3 complete versions of DB2....
If it were a known issue, I would agree with that. Maybe it just never
seemed to matter? Has anyone else seen this and is there some kind of a work-around ??
The work-around is not to try to pass a null value to a column which
has a "not null" constraint. Is there a default value defined? If so,
just leave that column out of any INSERT statements.
ahhh, yup...
OK, you did say the column is nullable ... I would (a) look for a
possible setting on the DB2 side of things, and (b) look into doing
the updates through a stored procedure.
--
Bob Hairgrove No**********@Home.com
On Fri, 06 Feb 2004 13:49:05 +0100, Bob Hairgrove
<wouldnt_you_like@to_know.com> wrote: On Thu, 05 Feb 2004 21:28:50 GMT, kurt.wood@NO**@M.state.mn.us (Remove
the obvious for replies) wrote:
There is a big difference between NULL and an empty string. ADO is an
ActiveX layer around ODBC, AFAIK. NULLs have been around since
prehistoric (DBMS) times. You need to distinguish between the two.
I have a firm grip on what null is and what an empty string is.
OK. I apologize if I sounded condescending ... I didn't mean to, just
trying to establish a common point of agreement. You might be
surprised to see how many people don't know the difference, especially
when coming from Access or VB.
In this , we have a "nullable" field with a list of 4 possible values. If
on the VB form, we delete the value in the control, then behind the
scenes we trap for an empty string, convert that to a null and try to
pass that to the database. This works fine on a 7.2 client, but with
an 8.1.4 client, our null is "reconverted" to an empty string.
How are you defining a "NULL" value on the client side? If the
We define null by setting it to VBNullString (also VBNull and
VBNullChar)
Is it a matter of bind variables? Or are you constructing the SQL
completely as text?
ODBC hanldes the low level operations for the ADO calls.
Hmmm ... since nothing has changed on the VB/ADO side, I suppose that
it was passing an empty string all along. Only the DB2 client has
changed.
I wonder if there is a setting in the DB2 client or server which would
influence how the database handles empty strings? I believe that with
Oracle, for example, there is a parameter for this. I know because we
had a procedure with a little lookup table and querying for NULL
worked in our test environment, but failed in production because it
was either returning a single space or an empty string.
What about doing the updates through a stored procedure? Or a
BeforeUpdate/BeforeInsert trigger?
I considered that. I thought if I passed a bogus date (say 12-31-1899)
thru and then I could use a trigger to change that to null. It would
work, but considering I would have to apply it to more that 300
tables, it doesn't seem to be the best solution.I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
They are probably right. Maybe, but that would sure show poor QA/QC in allowing an error to
propagate thru 3 complete versions of DB2....
If it were a known issue, I would agree with that. Maybe it just never
seemed to matter?
Has anyone else seen this and is there some kind of a work-around ??
The work-around is not to try to pass a null value to a column which
has a "not null" constraint. Is there a default value defined? If so,
just leave that column out of any INSERT statements.
ahhh, yup...
OK, you did say the column is nullable ... I would (a) look for a
possible setting on the DB2 side of things, and (b) look into doing
the updates through a stored procedure.
Here again, I could use a stored proc, but this seems like more of a
large scale change than I was hoping for. I still beleive the DB2
client is malfunctioning to a degree.These same routines worked in UDB
5.x, 6.x and 7.x and similar ones run perfect with ADO and Oracle 8.
The only odd-ball is UDB 8.1.4 . Coincicence ? Maybe, but I am not
thinking so.
--
Bob Hairgrove
No**********@Home.com
In the configuration assistant (CA), there is a Optimize for ...
and vb is in the list.
Maybe it does set a parm to fix your problem.
I made a test and by default for vb, it uses
PATCH2=6
PATCH1=1024
LOBMAXCOLUMNSIZE=1048575
LONGDATACOMPAT=1
6 Forces the driver to return a message indicating that scrollable
cursors are not supported. This setting is needed by some applications (such
as Visual Basic) that make use of LOBs or that do not need or want
scrollable cursors to be used, even though they have been explicitly
requested by the application.
1024 Returns SQL_SUCCESS instead of SQL_NO_DATA_FOUND from the
SQLExecute() and SQLExecDirect() functions if the executed UPDATE or DELETE
statement affected no rows. This value may be needed by some Microsoft
Visual Basic applications.
Humm....
Well, there is nothing here that would help in this case.
PM
Remove the obvious for replies wrote: Recently I have converted from UDB 7.2 (NT) to UDB 8.1.4 (W2K) and
have noticed a critical error W.R.T. our VB/ADO apps.
If I use the 7.2 client, then everything (except calls to federated
views) works great. If I use the 8.1.4 client, then I cannot send a
null or blank date back to the database (invalid format). I also
cannot null out the value of a field that has contraints on it
because the null get converted to an empty string (supposedly by ADO)
and that is not a valid value in the contraint list.
I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
Has anyone else seen this and is there some kind of a work-around ??
You may find something useful on this site (which I discovered recently),
under the "ADO enumerations" link - http://www.connectionstrings.com
We were able to use this to solve a number of problems we had with ADO and
DB2, by picking the right enumerations to set.
HTH
Phil
Thanks for trying , I have been thru all the CLI settings. In fact, we
have found that PATH2=6 and PATCH1=1408 seem to work the best in
previous versions.
On Fri, 6 Feb 2004 11:03:22 -0500, "PM \(pm3iinc-nospam\)"
<PM(pm3iinc-nospam)@sympatico.ca> wrote: In the configuration assistant (CA), there is a Optimize for ...
and vb is in the list.
Maybe it does set a parm to fix your problem.
I made a test and by default for vb, it uses
PATCH2=6
PATCH1=1024
LOBMAXCOLUMNSIZE=1048575
LONGDATACOMPAT=1
6 Forces the driver to return a message indicating that scrollable
cursors are not supported. This setting is needed by some applications (such
as Visual Basic) that make use of LOBs or that do not need or want
scrollable cursors to be used, even though they have been explicitly
requested by the application.
1024 Returns SQL_SUCCESS instead of SQL_NO_DATA_FOUND from the
SQLExecute() and SQLExecDirect() functions if the executed UPDATE or DELETE
statement affected no rows. This value may be needed by some Microsoft
Visual Basic applications.
Humm....
Well, there is nothing here that would help in this case.
PM
Thanks for the info, but it did not tell me anything that would help.
On Fri, 06 Feb 2004 23:03:12 GMT, Philip Nelson <gu*****@yahoo.co.uk>
wrote: Remove the obvious for replies wrote:
Recently I have converted from UDB 7.2 (NT) to UDB 8.1.4 (W2K) and
have noticed a critical error W.R.T. our VB/ADO apps.
If I use the 7.2 client, then everything (except calls to federated
views) works great. If I use the 8.1.4 client, then I cannot send a
null or blank date back to the database (invalid format). I also
cannot null out the value of a field that has contraints on it
because the null get converted to an empty string (supposedly by ADO)
and that is not a valid value in the contraint list.
I have opend a PMR with IBM, but they are saying the only reason that
these problems didn't show up in previous versions is because there
was an error in those versions that accidently allows those values to
pass and that the version 8 client is working as expected.
Has anyone else seen this and is there some kind of a work-around ??
You may find something useful on this site (which I discovered recently),
under the "ADO enumerations" link -
http://www.connectionstrings.com
We were able to use this to solve a number of problems we had with ADO and
DB2, by picking the right enumerations to set.
HTH
Phil This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Collin VanDyck |
last post by:
I have a basic understanding of this, so forgive me if I am overly
simplistic in my explanation of my problem..
I am trying to get a Java/Xalan transform to pass through a numeric
character...
|
by: DrTebi |
last post by:
Hello,
I have the following problem:
I used to "encode" my email address within links, in order to avoid (most)
email spiders. So I had a link like this:
<a...
|
by: Thomas Scheffler |
last post by:
Hi,
I runned in trouble using XALAN for XSL-Transformation.
The following snipplet show what I mean:
<a href="http://blah.com/?test=test&test2=test2">Test1&</a>
<a...
|
by: johkar |
last post by:
When the output method is set to xml, even though I have CDATA around
my JavaScript, the operaters of && and < are converted to XML character
entities which causes errors in my JavaScript. I know...
|
by: Nathan Sokalski |
last post by:
I add a JavaScript event handler to some of my Webcontrols using the
Attributes.Add() method as follows:
Dim jscode as String = "return (event.keyCode>=65&&event.keyCode<=90);"...
|
by: Jeremy |
last post by:
How can one stop a browser from converting
&
to
& ?
We have a textarea in our system wehre a user can type in some html code
and have it saved to the database. When the data is retireved...
|
by: Arne |
last post by:
A lot of Firefox users I know, says they have problems with validation
where the ampersand sign has to be written as & to be valid. I don't
have Firefox my self and don't wont to install it only...
|
by: InvalidLastName |
last post by:
We have been used XslTransform. .NET 1.1, for transform XML document, Dataset with xsl to HTML. Some of these html contents contain javascript and links. For example:
// javascript
if (a > b)...
|
by: John Nagle |
last post by:
I've been parsing existing HTML with BeautifulSoup, and occasionally
hit content which has something like "Design & Advertising", that is,
an "&" instead of an "&". Is there some way I can get...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
