DB2 Recordset information

"Kevin Knudson" <klk@knudsons.com> wrote:
>
>I've run into another problem with VB -> ADO -> UDB. Okay I open a recordset,
>selecting into it, and do a movelast (My program is restarting, so it looks
>at where the existing file ends, and compares it with the input file).

>
>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>adCmdText
>
>MasterTB.MoveLast
>
>UDB complains
>Rowset does not support fetching backwards.
>
>First any ideas, second is there a manual, reference something that defines
>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here and
nothing
>more than a couple of simple examples.
>
>There has to be some decent documentation somewhere.
>
I guess that the resulting dataset is unidirectional (you can only go from
first to last) and
not bidirectional (both ways)...

I've been thinking about this one. I think this happened to me.

What provider are you using?
What is your cursor location? MasterTB.CursorLocation = [what]
If you used the default(server) then change it to client.
Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?

If I remember correctly, the second one might be your problem.

Mark

"kevin knudson" <klk@knudsons.com> wrote:
>
>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>
>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>
>>>I've run into another problem with VB -> ADO -> UDB. Okay I open a recordset,
>>>selecting into it, and do a movelast (My program is restarting, so it
looks
>>>at where the existing file ends, and compares it with the input file).
>
>>
>>>
>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>adCmdText
>>>
>>>MasterTB.MoveLast
>>>
>>>UDB complains
>>>Rowset does not support fetching backwards.
>>>
>>>First any ideas, second is there a manual, reference something that defines
>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here and
>>nothing
>>>more than a couple of simple examples.
>>>
>>>There has to be some decent documentation somewhere.
>>>
>>I guess that the resulting dataset is unidirectional (you can only go from
>>first to last) and
>>not bidirectional (both ways)...
>
>Well actually if you note, I was going first to last, despite what the error
>message says.
>But I am still wondering does anyone have info on the UDB usage of the open
>modes, static, keyset, dynamic, lock modes etc. Are there different ones
>for UDB, how do they work etc.
>

You may want to use two cursors as workaround for bi-direction data scolling
and re-position the data being retrieved. I am not a VB guy just
a DBA.

"David" <djlin@sympatico.ca> wrote:
>

>"MarkN" <mnuttall@nospam.com> wrote:
>>
>>I've been thinking about this one. I think this happened to me.
>>
>>What provider are you using?
>>What is your cursor location? MasterTB.CursorLocation = [what]
>> If you used the default(server) then change it to client.
>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>
>>If I remember correctly, the second one might be your problem.
>>
>>Mark
>>
>>"kevin knudson" <klk@knudsons.com> wrote:
>>>
>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>
>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>
>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I open a
recordset,
>>>>>selecting into it, and do a movelast (My program is restarting, so it
>>looks
>>>>>at where the existing file ends, and compares it with the input file).
>>>
>>>>
>>>>>
>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>adCmdText
>>>>>
>>>>>MasterTB.MoveLast
>>>>>
>>>>>UDB complains
>>>>>Rowset does not support fetching backwards.
>>>>>
>>>>>First any ideas, second is there a manual, reference something that
defines
>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here
and
>>>>nothing
>>>>>more than a couple of simple examples.
>>>>>
>>>>>There has to be some decent documentation somewhere.
>>>>>
>>>>I guess that the resulting dataset is unidirectional (you can only go
>from
>>>>first to last) and
>>>>not bidirectional (both ways)...
>>>
>>>Well actually if you note, I was going first to last, despite what the
>error
>>>message says.
>>>But I am still wondering does anyone have info on the UDB usage of the
>open
>>>modes, static, keyset, dynamic, lock modes etc. Are there different ones
>>>for UDB, how do they work etc.
>>>
>>
>

I've found very little on the DB2 provider.

Here is a book from IBM that has ADO and VB info. Usually they are in PDF
format - not this one though so I don't know how good/useful it is.

http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246009.html?Open

"Kevin Knudson" <klk@knudsons.com> wrote:
>
>Thanks Mark, that was it.
>
>Although I'd still like to locate a writeup on ADO/OLEDB with UDB.
>
>
>KlK, MCSE
>EPS DBA
>
>"MarkN" <mnuttall@nospam.com> wrote:
>>
>>I've been thinking about this one. I think this happened to me.
>>
>>What provider are you using?
>>What is your cursor location? MasterTB.CursorLocation = [what]
>> If you used the default(server) then change it to client.
>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>
>>If I remember correctly, the second one might be your problem.
>>
>>Mark
>>
>>"kevin knudson" <klk@knudsons.com> wrote:
>>>
>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>
>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>
>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I open a
recordset,
>>>>>selecting into it, and do a movelast (My program is restarting, so it
>>looks
>>>>>at where the existing file ends, and compares it with the input file).
>>>
>>>>
>>>>>
>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>adCmdText
>>>>>
>>>>>MasterTB.MoveLast
>>>>>
>>>>>UDB complains
>>>>>Rowset does not support fetching backwards.
>>>>>
>>>>>First any ideas, second is there a manual, reference something that
defines
>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here
and
>>>>nothing
>>>>>more than a couple of simple examples.
>>>>>
>>>>>There has to be some decent documentation somewhere.
>>>>>
>>>>I guess that the resulting dataset is unidirectional (you can only go
>from
>>>>first to last) and
>>>>not bidirectional (both ways)...
>>>
>>>Well actually if you note, I was going first to last, despite what the
>error
>>>message says.
>>>But I am still wondering does anyone have info on the UDB usage of the
>open
>>>modes, static, keyset, dynamic, lock modes etc. Are there different ones
>>>for UDB, how do they work etc.
>>>
>>
>

Remember that you are using a MS product with an IBM product. I would expect
that ADO would work better with SQL Server. If it worked well with DB2 more
people might want to use that instead of SQL Server :) ;(. I wouldn't blame
the problems on UDB. Try using Java with SQL Server.

I've used DB2, SQL Server and Oracle (and others). DB2 is a very good product.
It is not perfect and neither is any other database. I was 'blessing' out
SQL Server last night.

In my development, I try to avoid manipulating recordsets and that helps
me avoid some problems. Yeah, it creates others but you have to pick your
poison.

You might want to consider Java if your shop is firm on big blue. It works
well with DB2 and all other big blue products - MQ Series/Lotus Notes/Websphere.

Mark

"kevin knudson" <klk@knudsons.com> wrote:
>
>Thanks Mark
>I ordered it today, should have it in a couple of days. We'll see if it's
>any good. I hope so.
>
>I've been meaning to post my latest, I have a recordset that I read and
update
>or insert, it contains paramaters and restart information. Works great
with
>SQL, errors out hard with UDB. Although I did make it better with a stored
>proc, thats not the point. It should work with UDB also.
>
>I wish my employer would see the issue's with UDB, but they are a big blue
>shop, so I don't expect much.
>
>Thanks Again
>
>KlK
>
>"MarkN" <mnuttall@nospam.com> wrote:
>>
>>I've found very little on the DB2 provider.
>>
>>Here is a book from IBM that has ADO and VB info. Usually they are in
PDF
>>format - not this one though so I don't know how good/useful it is.
>>
>>http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246009.html?Open
>>
>>
>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>
>>>Thanks Mark, that was it.
>>>
>>>Although I'd still like to locate a writeup on ADO/OLEDB with UDB.
>>>
>>>
>>>KlK, MCSE
>>>EPS DBA
>>>
>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>
>>>>I've been thinking about this one. I think this happened to me.
>>>>
>>>>What provider are you using?
>>>>What is your cursor location? MasterTB.CursorLocation = [what]
>>>> If you used the default(server) then change it to client.
>>>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>>>
>>>>If I remember correctly, the second one might be your problem.
>>>>
>>>>Mark
>>>>
>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>
>>>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>>>
>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>
>>>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I open
a
>>recordset,
>>>>>>>selecting into it, and do a movelast (My program is restarting, so
>it
>>>>looks
>>>>>>>at where the existing file ends, and compares it with the input file).
>>>>>
>>>>>>
>>>>>>>
>>>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>>>adCmdText
>>>>>>>
>>>>>>>MasterTB.MoveLast
>>>>>>>
>>>>>>>UDB complains
>>>>>>>Rowset does not support fetching backwards.
>>>>>>>
>>>>>>>First any ideas, second is there a manual, reference something that
>>defines
>>>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here
>>and
>>>>>>nothing
>>>>>>>more than a couple of simple examples.
>>>>>>>
>>>>>>>There has to be some decent documentation somewhere.
>>>>>>>
>>>>>>I guess that the resulting dataset is unidirectional (you can only
go
>>>from
>>>>>>first to last) and
>>>>>>not bidirectional (both ways)...
>>>>>
>>>>>Well actually if you note, I was going first to last, despite what the
>>>error
>>>>>message says.
>>>>>But I am still wondering does anyone have info on the UDB usage of the
>>>open
>>>>>modes, static, keyset, dynamic, lock modes etc. Are there different
>ones
>>>>>for UDB, how do they work etc.
>>>>>
>>>>
>>>
>>
>

Ok, so you got me on some of those. (I am more developer than DBA) UDB does
have some catching up to do in the visual department. I avoid stored procs/triggers
as much a possible because they basically lock you into a database so I don't
know much about UDB Stored procs.

I've run into the same type of problems with Oracle. And you will find problems
with SQL Server too. Like logging bombing out and some wierd stuff that
I can't remember. And it only works on Windows. UDB is available on most
platforms and that might be the cause of some of its problems.

If an application is architected in a certain way, it can be easily converted
to use another database. Some applications may be able to immediately switched
over, but most will require some conversion. Heavy reliance on recordset
manipulation, databound controls, non-standard SQL and stored procs will
make it very tough to convert.

I would say most programs that have been written would not easily converted
because. Speed and initial development are usually more important than DB
(platform/tool/etc.) independence.

Glad to know you know the low level DB2 stuff. I may have some questions
for you.

Mark

"kevin knudson" <klk@knudsons.com> wrote:
>
>Well fortunately I'm a DBA here, not a developer. But I have a number of
>programs at home using SQL, so I thought I'd convert them to UDB as the
architects
>here seem to think you just take SQL programs and point them to UDB. I
tried
>telling them, but hey I've only been in IT 30 years.
>
>No, I have found more UDB problems with UDB than ODBC problems.
>Sorry the underlying engine may be pretty good, but the Control Center,
and
>Stored Procedure builder are full of junior programmer bugs.
>
>And a couple of major design flaws, try and allocate a 1 gig SMS tablespace,
>sorry it has to be built 1 meg at a time, and if you don't read the manual
>REAL close you will actually get 1 meg and ? 4k extents.
>
>Well I'm getting off my soapbox, and heading home.
>
>KlK, MCSE
>
>
>"MarkN" <mnuttall@nospam.com> wrote:
>>
>>Remember that you are using a MS product with an IBM product. I would
expect
>>that ADO would work better with SQL Server. If it worked well with DB2
>more
>>people might want to use that instead of SQL Server :) ;(. I wouldn't
blame
>>the problems on UDB. Try using Java with SQL Server.
>>
>>I've used DB2, SQL Server and Oracle (and others). DB2 is a very good
product.
>> It is not perfect and neither is any other database. I was 'blessing'
>out
>>SQL Server last night.
>>
>>In my development, I try to avoid manipulating recordsets and that helps
>>me avoid some problems. Yeah, it creates others but you have to pick your
>>poison.
>>
>>You might want to consider Java if your shop is firm on big blue. It works
>>well with DB2 and all other big blue products - MQ Series/Lotus Notes/Websphere.
>>
>>
>>Mark
>>
>>
>>"kevin knudson" <klk@knudsons.com> wrote:
>>>
>>>Thanks Mark
>>>I ordered it today, should have it in a couple of days. We'll see if
it's
>>>any good. I hope so.
>>>
>>>I've been meaning to post my latest, I have a recordset that I read and
>>update
>>>or insert, it contains paramaters and restart information. Works great
>>with
>>>SQL, errors out hard with UDB. Although I did make it better with a stored
>>>proc, thats not the point. It should work with UDB also.
>>>
>>>I wish my employer would see the issue's with UDB, but they are a big
blue
>>>shop, so I don't expect much.
>>>
>>>Thanks Again
>>>
>>>KlK
>>>
>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>
>>>>I've found very little on the DB2 provider.
>>>>
>>>>Here is a book from IBM that has ADO and VB info. Usually they are in
>>PDF
>>>>format - not this one though so I don't know how good/useful it is.
>>>>
>>>>http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246009.html?Open
>>>>
>>>>
>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>
>>>>>Thanks Mark, that was it.
>>>>>
>>>>>Although I'd still like to locate a writeup on ADO/OLEDB with UDB.
>>>>>
>>>>>
>>>>>KlK, MCSE
>>>>>EPS DBA
>>>>>
>>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>>
>>>>>>I've been thinking about this one. I think this happened to me.
>>>>>>
>>>>>>What provider are you using?
>>>>>>What is your cursor location? MasterTB.CursorLocation = [what]
>>>>>> If you used the default(server) then change it to client.
>>>>>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>>>>>
>>>>>>If I remember correctly, the second one might be your problem.
>>>>>>
>>>>>>Mark
>>>>>>
>>>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>>>
>>>>>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>>>>>
>>>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>>>
>>>>>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I open
>>a
>>>>recordset,
>>>>>>>>>selecting into it, and do a movelast (My program is restarting,
so
>>>it
>>>>>>looks
>>>>>>>>>at where the existing file ends, and compares it with the input
file).
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>>>>>adCmdText
>>>>>>>>>
>>>>>>>>>MasterTB.MoveLast
>>>>>>>>>
>>>>>>>>>UDB complains
>>>>>>>>>Rowset does not support fetching backwards.
>>>>>>>>>
>>>>>>>>>First any ideas, second is there a manual, reference something that
>>>>defines
>>>>>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual here
>>>>and
>>>>>>>>nothing
>>>>>>>>>more than a couple of simple examples.
>>>>>>>>>
>>>>>>>>>There has to be some decent documentation somewhere.
>>>>>>>>>
>>>>>>>>I guess that the resulting dataset is unidirectional (you can only
>>go
>>>>>from
>>>>>>>>first to last) and
>>>>>>>>not bidirectional (both ways)...
>>>>>>>
>>>>>>>Well actually if you note, I was going first to last, despite what
>the
>>>>>error
>>>>>>>message says.
>>>>>>>But I am still wondering does anyone have info on the UDB usage of
>the
>>>>>open
>>>>>>>modes, static, keyset, dynamic, lock modes etc. Are there different
>>>ones
>>>>>>>for UDB, how do they work etc.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Kevin,

Thanks for the clarification. I understand/feel your frustration.

A lot of newbies/inexperienced people use these newsgroups (or I gather from
the postings) and I didn't want them to get the wrong idea.

I have the same issue with conflicting updates. I try to keep data access
off of user machines and also objectize the persistance. It drives me nuts
when my client side DB access is screwed because someone installed AOL or
something else.

To avoid using recordset/record locking we've used a trigger (one of the
exceptions I was refering to) and a last updated field. I think once we
move to EJBs(next step) that we can do away with it. Maybe that is something
you should look into. Unfortunately there presently(and I don't think near
future) is no Microsoft equiv.

Mark

"kevin knudson" <klk@knudsons.com> wrote:
>
>Well, I do a lot of development at home, here I support UDB and SQL on NT.
>We do have a lot of UNIX / AIX UDB, as well as Oracle. I'm supposed to
be
>learning UNIX as time permits. I'm not really knocking UDB, just from an
>adminstration standpoint (I feel) it is a nightmare. Although we are evaluating
>some software from Quest that replaces Control Center, and it's fast and
>stable. Which is definitely more than I can say for Control Center.
>
>I do try and learn as much as I can down to the deepest level on anything
>I work on. I worked on Mainframes for many years doing just about everything
>from systems programming to development. And knew CICS and IMS (and COBOL)
>pretty well.
>
>So feel free to ask, I've been pushing my UDB box at home pretty good.
So
>far, while not scientific but apples to apples, SQL is slightly faster.

>I'm just working on the "Out of the Box" type configuration, just creating
>the DBs by the book. No fancy tuning, but the 2 DBs (SQL and UDB) are configured
>as close as possible. So far SQL is marginally faster. Although I've had
>to change the program somewhat (usually for the better) to make it compatible
>for either DBMS.
>
>Once winter sets in I plan to rerun these tests, then take the 2 and tune
>them the best I can, with my relatively limited hardware, and really compare
>them.
>
>Regarding languages, we have a real mismash around here, but I don't get
>real involved in that side of it. Mostly Visual Age, and UltraDev (?) for
>web. Internally pick a language we've got something written in it here.
>
>Stored procedures, actually once you learn a couple of simple things they
>make the programs much more transportable. But I still have an area I need
>a dynamic recordset, and I hope that book will get me past it. I run a
program
>that updates the DB from multiple workstations and use the recordset to
control
>locking so they don't attempt to update the same place. I may have a stored
>procedure alternative, but haven't had the time to play with it.
>
>Well best wishes, don't take my knocking of UDB too seriously, after 30
years
>working on IBM stuff I guess just expected better.
>
>I just get upset sometimes the way people knock NT for crashing, I have
2
>servers and 3 workstations at home (NT4 SBS, NT2K servers, NT4, and 2 98
>workstations) and the only time they come down is powerfails or if I want
>to knock them down. And I abuse all of the NT boxes pretty well.
>
>KlK, MCSE
>
>"MarkN" <mnuttall@nospam.com> wrote:
>>
>>Ok, so you got me on some of those. (I am more developer than DBA) UDB
>does
>>have some catching up to do in the visual department. I avoid stored procs/triggers
>>as much a possible because they basically lock you into a database so I
>don't
>>know much about UDB Stored procs.
>>
>>I've run into the same type of problems with Oracle. And you will find
>problems
>>with SQL Server too. Like logging bombing out and some wierd stuff that
>>I can't remember. And it only works on Windows. UDB is available on most
>>platforms and that might be the cause of some of its problems.
>>
>>If an application is architected in a certain way, it can be easily converted
>>to use another database. Some applications may be able to immediately
switched
>>over, but most will require some conversion. Heavy reliance on recordset
>>manipulation, databound controls, non-standard SQL and stored procs will
>>make it very tough to convert.
>>
>>I would say most programs that have been written would not easily converted
>>because. Speed and initial development are usually more important than
>DB
>>(platform/tool/etc.) independence.
>>
>>Glad to know you know the low level DB2 stuff. I may have some questions
>>for you.
>>
>>Mark
>>
>>"kevin knudson" <klk@knudsons.com> wrote:
>>>
>>>Well fortunately I'm a DBA here, not a developer. But I have a number
>of
>>>programs at home using SQL, so I thought I'd convert them to UDB as the
>>architects
>>>here seem to think you just take SQL programs and point them to UDB.
I
>>tried
>>>telling them, but hey I've only been in IT 30 years.
>>>
>>>No, I have found more UDB problems with UDB than ODBC problems.
>>>Sorry the underlying engine may be pretty good, but the Control Center,
>>and
>>>Stored Procedure builder are full of junior programmer bugs.
>>>
>>>And a couple of major design flaws, try and allocate a 1 gig SMS tablespace,
>>>sorry it has to be built 1 meg at a time, and if you don't read the manual
>>>REAL close you will actually get 1 meg and ? 4k extents.
>>>
>>>Well I'm getting off my soapbox, and heading home.
>>>
>>>KlK, MCSE
>>>
>>>
>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>
>>>>Remember that you are using a MS product with an IBM product. I would
>>expect
>>>>that ADO would work better with SQL Server. If it worked well with DB2
>>>more
>>>>people might want to use that instead of SQL Server :) ;(. I wouldn't
>>blame
>>>>the problems on UDB. Try using Java with SQL Server.
>>>>
>>>>I've used DB2, SQL Server and Oracle (and others). DB2 is a very good
>>product.
>>>> It is not perfect and neither is any other database. I was 'blessing'
>>>out
>>>>SQL Server last night.
>>>>
>>>>In my development, I try to avoid manipulating recordsets and that helps
>>>>me avoid some problems. Yeah, it creates others but you have to pick
>your
>>>>poison.
>>>>
>>>>You might want to consider Java if your shop is firm on big blue. It
>works
>>>>well with DB2 and all other big blue products - MQ Series/Lotus Notes/Websphere.
>>>>
>>>>
>>>>Mark
>>>>
>>>>
>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>
>>>>>Thanks Mark
>>>>>I ordered it today, should have it in a couple of days. We'll see if
>>it's
>>>>>any good. I hope so.
>>>>>
>>>>>I've been meaning to post my latest, I have a recordset that I read
and
>>>>update
>>>>>or insert, it contains paramaters and restart information. Works great
>>>>with
>>>>>SQL, errors out hard with UDB. Although I did make it better with a
>stored
>>>>>proc, thats not the point. It should work with UDB also.
>>>>>
>>>>>I wish my employer would see the issue's with UDB, but they are a big
>>blue
>>>>>shop, so I don't expect much.
>>>>>
>>>>>Thanks Again
>>>>>
>>>>>KlK
>>>>>
>>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>>
>>>>>>I've found very little on the DB2 provider.
>>>>>>
>>>>>>Here is a book from IBM that has ADO and VB info. Usually they are
>in
>>>>PDF
>>>>>>format - not this one though so I don't know how good/useful it is.
>>>>>>
>>>>>>http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246009.html?Open
>>>>>>
>>>>>>
>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>
>>>>>>>Thanks Mark, that was it.
>>>>>>>
>>>>>>>Although I'd still like to locate a writeup on ADO/OLEDB with UDB.
>
>>>>>>>
>>>>>>>
>>>>>>>KlK, MCSE
>>>>>>>EPS DBA
>>>>>>>
>>>>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>>>>
>>>>>>>>I've been thinking about this one. I think this happened to me.

>>>>>>>>
>>>>>>>>What provider are you using?
>>>>>>>>What is your cursor location? MasterTB.CursorLocation = [what]
>>>>>>>> If you used the default(server) then change it to client.
>>>>>>>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>>>>>>>
>>>>>>>>If I remember correctly, the second one might be your problem.
>>>>>>>>
>>>>>>>>Mark
>>>>>>>>
>>>>>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>>>>>
>>>>>>>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>>>>>>>
>>>>>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I open
>>>>a
>>>>>>recordset,
>>>>>>>>>>>selecting into it, and do a movelast (My program is restarting,
>>so
>>>>>it
>>>>>>>>looks
>>>>>>>>>>>at where the existing file ends, and compares it with the input
>>file).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>>>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>>>>>>>adCmdText
>>>>>>>>>>>
>>>>>>>>>>>MasterTB.MoveLast
>>>>>>>>>>>
>>>>>>>>>>>UDB complains
>>>>>>>>>>>Rowset does not support fetching backwards.
>>>>>>>>>>>
>>>>>>>>>>>First any ideas, second is there a manual, reference something
>that
>>>>>>defines
>>>>>>>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual
>here
>>>>>>and
>>>>>>>>>>nothing
>>>>>>>>>>>more than a couple of simple examples.
>>>>>>>>>>>
>>>>>>>>>>>There has to be some decent documentation somewhere.
>>>>>>>>>>>
>>>>>>>>>>I guess that the resulting dataset is unidirectional (you can only
>>>>go
>>>>>>>from
>>>>>>>>>>first to last) and
>>>>>>>>>>not bidirectional (both ways)...
>>>>>>>>>
>>>>>>>>>Well actually if you note, I was going first to last, despite what
>>>the
>>>>>>>error
>>>>>>>>>message says.
>>>>>>>>>But I am still wondering does anyone have info on the UDB usage
of
>>>the
>>>>>>>open
>>>>>>>>>modes, static, keyset, dynamic, lock modes etc. Are there different
>>>>>ones
>>>>>>>>>for UDB, how do they work etc.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

FYI I got that book a while back, so far I think it should be in the fiction
category, take the IBM manuals massage them and reprint.

They gloss over a lot of problem areas, I get the impression there is little
real world experience between them. Wish I'd have gotten the company to
but the book instead of me personally.

But thanks, you did say you hadn't seen it so I took my own chances.

KlK, MCSE

"MarkN" <mnuttall@nospam.com> wrote:
>
>Kevin,
>
>Thanks for the clarification. I understand/feel your frustration.
>
>A lot of newbies/inexperienced people use these newsgroups (or I gather
from
>the postings) and I didn't want them to get the wrong idea.
>
>I have the same issue with conflicting updates. I try to keep data access
>off of user machines and also objectize the persistance. It drives me nuts
>when my client side DB access is screwed because someone installed AOL or
>something else.
>
>To avoid using recordset/record locking we've used a trigger (one of the
>exceptions I was refering to) and a last updated field. I think once we
>move to EJBs(next step) that we can do away with it. Maybe that is something
>you should look into. Unfortunately there presently(and I don't think near
>future) is no Microsoft equiv.
>
>Mark
>
>"kevin knudson" <klk@knudsons.com> wrote:
>>
>>Well, I do a lot of development at home, here I support UDB and SQL on
NT.
>>We do have a lot of UNIX / AIX UDB, as well as Oracle. I'm supposed to
>be
>>learning UNIX as time permits. I'm not really knocking UDB, just from
an
>>adminstration standpoint (I feel) it is a nightmare. Although we are evaluating
>>some software from Quest that replaces Control Center, and it's fast and
>>stable. Which is definitely more than I can say for Control Center.
>>
>>I do try and learn as much as I can down to the deepest level on anything
>>I work on. I worked on Mainframes for many years doing just about everything
>>from systems programming to development. And knew CICS and IMS (and COBOL)
>>pretty well.
>>
>>So feel free to ask, I've been pushing my UDB box at home pretty good.

>So
>>far, while not scientific but apples to apples, SQL is slightly faster.
>
>>I'm just working on the "Out of the Box" type configuration, just creating
>>the DBs by the book. No fancy tuning, but the 2 DBs (SQL and UDB) are configured
>>as close as possible. So far SQL is marginally faster. Although I've
had
>>to change the program somewhat (usually for the better) to make it compatible
>>for either DBMS.
>>
>>Once winter sets in I plan to rerun these tests, then take the 2 and tune
>>them the best I can, with my relatively limited hardware, and really compare
>>them.
>>
>>Regarding languages, we have a real mismash around here, but I don't get
>>real involved in that side of it. Mostly Visual Age, and UltraDev (?)
for
>>web. Internally pick a language we've got something written in it here.
>>
>>Stored procedures, actually once you learn a couple of simple things they
>>make the programs much more transportable. But I still have an area I need
>>a dynamic recordset, and I hope that book will get me past it. I run a
>program
>>that updates the DB from multiple workstations and use the recordset to
>control
>>locking so they don't attempt to update the same place. I may have a stored
>>procedure alternative, but haven't had the time to play with it.
>>
>>Well best wishes, don't take my knocking of UDB too seriously, after 30
>years
>>working on IBM stuff I guess just expected better.
>>
>>I just get upset sometimes the way people knock NT for crashing, I have
>2
>>servers and 3 workstations at home (NT4 SBS, NT2K servers, NT4, and 2 98
>>workstations) and the only time they come down is powerfails or if I want
>>to knock them down. And I abuse all of the NT boxes pretty well.
>>
>>KlK, MCSE
>>
>>"MarkN" <mnuttall@nospam.com> wrote:
>>>
>>>Ok, so you got me on some of those. (I am more developer than DBA) UDB
>>does
>>>have some catching up to do in the visual department. I avoid stored
procs/triggers
>>>as much a possible because they basically lock you into a database so
I
>>don't
>>>know much about UDB Stored procs.
>>>
>>>I've run into the same type of problems with Oracle. And you will find
>>problems
>>>with SQL Server too. Like logging bombing out and some wierd stuff that
>>>I can't remember. And it only works on Windows. UDB is available on
most
>>>platforms and that might be the cause of some of its problems.
>>>
>>>If an application is architected in a certain way, it can be easily converted
>>>to use another database. Some applications may be able to immediately
>switched
>>>over, but most will require some conversion. Heavy reliance on recordset
>>>manipulation, databound controls, non-standard SQL and stored procs will
>>>make it very tough to convert.
>>>
>>>I would say most programs that have been written would not easily converted
>>>because. Speed and initial development are usually more important than
>>DB
>>>(platform/tool/etc.) independence.
>>>
>>>Glad to know you know the low level DB2 stuff. I may have some questions
>>>for you.
>>>
>>>Mark
>>>
>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>
>>>>Well fortunately I'm a DBA here, not a developer. But I have a number
>>of
>>>>programs at home using SQL, so I thought I'd convert them to UDB as the
>>>architects
>>>>here seem to think you just take SQL programs and point them to UDB.

>I
>>>tried
>>>>telling them, but hey I've only been in IT 30 years.
>>>>
>>>>No, I have found more UDB problems with UDB than ODBC problems.
>>>>Sorry the underlying engine may be pretty good, but the Control Center,
>>>and
>>>>Stored Procedure builder are full of junior programmer bugs.
>>>>
>>>>And a couple of major design flaws, try and allocate a 1 gig SMS tablespace,
>>>>sorry it has to be built 1 meg at a time, and if you don't read the manual
>>>>REAL close you will actually get 1 meg and ? 4k extents.
>>>>
>>>>Well I'm getting off my soapbox, and heading home.
>>>>
>>>>KlK, MCSE
>>>>
>>>>
>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>
>>>>>Remember that you are using a MS product with an IBM product. I would
>>>expect
>>>>>that ADO would work better with SQL Server. If it worked well with
DB2
>>>>more
>>>>>people might want to use that instead of SQL Server :) ;(. I wouldn't
>>>blame
>>>>>the problems on UDB. Try using Java with SQL Server.
>>>>>
>>>>>I've used DB2, SQL Server and Oracle (and others). DB2 is a very good
>>>product.
>>>>> It is not perfect and neither is any other database. I was 'blessing'
>>>>out
>>>>>SQL Server last night.
>>>>>
>>>>>In my development, I try to avoid manipulating recordsets and that helps
>>>>>me avoid some problems. Yeah, it creates others but you have to pick
>>your
>>>>>poison.
>>>>>
>>>>>You might want to consider Java if your shop is firm on big blue. It
>>works
>>>>>well with DB2 and all other big blue products - MQ Series/Lotus Notes/Websphere.
>>>>>
>>>>>
>>>>>Mark
>>>>>
>>>>>
>>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>>
>>>>>>Thanks Mark
>>>>>>I ordered it today, should have it in a couple of days. We'll see
if
>>>it's
>>>>>>any good. I hope so.
>>>>>>
>>>>>>I've been meaning to post my latest, I have a recordset that I read
>and
>>>>>update
>>>>>>or insert, it contains paramaters and restart information. Works great
>>>>>with
>>>>>>SQL, errors out hard with UDB. Although I did make it better with
a
>>stored
>>>>>>proc, thats not the point. It should work with UDB also.
>>>>>>
>>>>>>I wish my employer would see the issue's with UDB, but they are a big
>>>blue
>>>>>>shop, so I don't expect much.
>>>>>>
>>>>>>Thanks Again
>>>>>>
>>>>>>KlK
>>>>>>
>>>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>>>
>>>>>>>I've found very little on the DB2 provider.
>>>>>>>
>>>>>>>Here is a book from IBM that has ADO and VB info. Usually they are
>>in
>>>>>PDF
>>>>>>>format - not this one though so I don't know how good/useful it is.
>>>>>>>
>>>>>>>http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246009.html?Open
>>>>>>>
>>>>>>>
>>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>>
>>>>>>>>Thanks Mark, that was it.
>>>>>>>>
>>>>>>>>Although I'd still like to locate a writeup on ADO/OLEDB with UDB.
>>
>>>>>>>>
>>>>>>>>
>>>>>>>>KlK, MCSE
>>>>>>>>EPS DBA
>>>>>>>>
>>>>>>>>"MarkN" <mnuttall@nospam.com> wrote:
>>>>>>>>>
>>>>>>>>>I've been thinking about this one. I think this happened to me.
>
>>>>>>>>>
>>>>>>>>>What provider are you using?
>>>>>>>>>What is your cursor location? MasterTB.CursorLocation = [what]
>>>>>>>>> If you used the default(server) then change it to client.
>>>>>>>>>Have you tried 'MasterTB.MoveNext until MasterTB.EOF'?
>>>>>>>>>
>>>>>>>>>If I remember correctly, the second one might be your problem.
>>>>>>>>>
>>>>>>>>>Mark
>>>>>>>>>
>>>>>>>>>"kevin knudson" <klk@knudsons.com> wrote:
>>>>>>>>>>
>>>>>>>>>>"lsae" <lsaenen@bru-hub.dhl.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>"Kevin Knudson" <klk@knudsons.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>I've run into another problem with VB -> ADO -> UDB. Okay I
open
>>>>>a
>>>>>>>recordset,
>>>>>>>>>>>>selecting into it, and do a movelast (My program is restarting,
>>>so
>>>>>>it
>>>>>>>>>looks
>>>>>>>>>>>>at where the existing file ends, and compares it with the input
>>>file).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>MasterTB.Open "SELECT Symbol,Exchange,OEX100,ScanDate,ScanFlag,Optionable
>>>>>>>>>>>>FROM StkMaster ORDER BY Symbol", ConnMstr, adOpenStatic, adLockReadOnly,
>>>>>>>>>>>>adCmdText
>>>>>>>>>>>>
>>>>>>>>>>>>MasterTB.MoveLast
>>>>>>>>>>>>
>>>>>>>>>>>>UDB complains
>>>>>>>>>>>>Rowset does not support fetching backwards.
>>>>>>>>>>>>
>>>>>>>>>>>>First any ideas, second is there a manual, reference something
>>that
>>>>>>>defines
>>>>>>>>>>>>how to access a UDB DB via ADO/OLEDB. I have every DB2 manual
>>here
>>>>>>>and
>>>>>>>>>>>nothing
>>>>>>>>>>>>more than a couple of simple examples.
>>>>>>>>>>>>
>>>>>>>>>>>>There has to be some decent documentation somewhere.
>>>>>>>>>>>>
>>>>>>>>>>>I guess that the resulting dataset is unidirectional (you can
only
>>>>>go
>>>>>>>>from
>>>>>>>>>>>first to last) and
>>>>>>>>>>>not bidirectional (both ways)...
>>>>>>>>>>
>>>>>>>>>>Well actually if you note, I was going first to last, despite what
>>>>the
>>>>>>>>error
>>>>>>>>>>message says.
>>>>>>>>>>But I am still wondering does anyone have info on the UDB usage
>of
>>>>the
>>>>>>>>open
>>>>>>>>>>modes, static, keyset, dynamic, lock modes etc. Are there different
>>>>>>ones
>>>>>>>>>>for UDB, how do they work etc.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

I wouldn't say worthless, it's just the way they show how it should / will
/ might work. There are some parts that are interesting.
I have a very good SQL Server book, that has a few holes in it(one REALLY
big one).

I think the problem with these publishers is they have a writer write the
book from the product documentation. I wish they would get someone with
some real world experience in the product to at least review, if not correct,
or better yet give some "real" world input. Although I know most of us techies
are not great writers.

KlK, MCSE

"MarkN" <mnuttall@nospam.com> wrote:
>
>Sorry that it was worthless. I would venture a guess and say that most
ADO
>work done uses SQL Server and then maybe Oracle. That is part of the reason
>that there is not much in the way of docs. DB2 has seem to just recently
>become a more "popular" Windows database. Oh well, let me know how it goes.
> I may still have some questions for you.
>
>Mark