RE: SQL Reporting Services

Hi Thomas,

Within Reporting Services, you can't use the iSeries .NET provider, nor can
you write the code directly to the API(s). You create a "Dataset" by writing
straight SQL, and the reporting engine converts that to the API calls as
necessary. Therein lies the problem; "call mySchema.myProc (myParm)" is not
a valid syntax within Reporting Services, although it works just fine when
coding against the OLEDB API directly.

With respect to the comparison versus Crystal, I personally find Crystal
easier to create reports in, but that's because I'm familiar with it. The
main advantage to Reporting Services for us is that it's all server based.
Deploying the Crystal runtime can be a nightmare sometimes. Crystal does
offer a server based reporting solution, but I've never tried it because
it's simply too expensive. Reporting Services is bundled with SQL Server, so
there is no extra charge to use it.


Regards,

John Taylor

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Gard
Sent: Wednesday, May 30, 2007 6:20 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: SQL Reporting Services

I have gotten an sql stored procedure on the iseries to be
successfully called in vb.net. My experience is limited but
try to learn as I go. I believe a stored procedure that is
made with embeded sql and rpgle may work differently than a
stored procedure made solely with sql, just fyi. Here is
some code, Im using the iseries for .net data provider. Have
you found the MS report writer to be better than crystal?

Dim sql As String = "call portal.sp_attydoe2(@doe)"
Dim cmd As New iDB2Command(SQL, cn)
cmd.Parameters.Add("@doe", iDB2DbType.iDB2Numeric, 8)
cmd.Parameters("@doe").Scale = 0
cmd.Parameters("@doe").Value = doe

'create a data reader object, fill it by executing the command
Dim dr As iDB2DataReader
Try
dr = cmd.ExecuteReader()
Catch ex As iDB2Exception
HandleError("an error occurred on
cmd.ExecuteReader()", ex)
Exit Sub
End Try