What I am doing is re-writing an RPG CRUD application as part of a new
Windows Form application. I'm not a .NET guru, but have done work on other
.NET projects, focused on the web (i.e., web-services using LINQ, WCF,
etc.) instead of IBM i & DB2. So I am trying to figure how best to do
things (i.e., what is best practice) given the tools I have available,
which are the 6.1 IBM data provider (i.e., .NET 2.0) and Visual Studio
Express 2010 (though I might be able to justify purchasing Professional
2008 or 2010). Unless, I go with 2008 Professional, it seems like I am out
of luck using the IBM data provider with visual tools and wizards inside
VS to develop typed data sets, but based on what you all are saying, that
may not be very efficient anyway. On the other hand, it seems spinning my
own typed datasets is non-trivial for a CRUD application, though I could
be wrong. I work best from examples or tutorials, if anyone has
recommendations, links or a book, I'd be appreciative. I've been looking
at "Data Binding with Windows Forms 2.0" by Brian Noyes. Most of the book
is on typed data sets developed using the VS tools, but he does talk about
implementing custom data-bound business objects and collections towards
the end. So I am thinking I could go that route. Again, any advice or
examples would be appreciated. Thanks.
Blake
------------------------------
I agree. I think I had this in the archives, but I was working on another
non-iSeries project and needed to access the vendor's MS SQL database.
LINQ
took about 15 minutes to retrieve 350 records, XSD took minutes, and my
own
code took seconds. Very important in any UI application.
--
Mike Wills
http://mikewills.info
On Wed, Jul 14, 2010 at 2:38 PM, Maurice O'Prey
<Maurice.oprey@xxxxxxxxx>wrote:
Manually coding your typed data sets and using the standard IBM data
provider (whichever version 5.3-6.1) is in my opinion the easiest option.
I
personally have found that when accessing iDB2 data you cannot expect
VS2010
to generate all the correct code for you due to differences in SQL syntax
etc. (plus your own design wishes)
It's not very difficult and there is no reason to get other ODBC/OLEDB
drivers involved IMHO
Maurice O'Prey
midrange.com
