Thursday, March 29, 2012
Cursor taking longer to open at every open
running opens, fetches and closes a cursor at regular
intervals. It is a 'greater-than-or-equal-to'
FAST_FORWARD, READONLY cursor. Isolation level is READ
UNCOMMITED. We use a dedicated connection for the
cursor. Using TCP/IP to connect.
The program is moving from the beginning of a million row
table, opening and closing the cursor every time it wants
a new row - it does not want every row. Bad code -
DEFINATELY! But a re-write may not be a usable option.
When I run my program locally (pointing to the database on
the server), it takes the same amount of time every time
the cursor is opened. The ODBC DSN is defined locally.
When I run the program directly on the server (same
database), the amount of time to open the cursor gets
progressivly worse. Almost as though on the server it is
reading from the beginning of the table everytime, and as
the program logically moves through the table. The ODBC
DSN is defined on the server.Just curious why you're using cursors and not the
preferred method of T-SQL, which would make your access
much faster. I know you mention bad code, but if it's
ingrained, and other than, say, making sure you have thr
right index or hints, there's not much you can do. SQL
Server is not best when used with cursors for large
things; using T-SQL is like night and day.
>--Original Message--
>I am connecting to a server using ODBC. The program I am
>running opens, fetches and closes a cursor at regular
>intervals. It is a 'greater-than-or-equal-to'
>FAST_FORWARD, READONLY cursor. Isolation level is READ
>UNCOMMITED. We use a dedicated connection for the
>cursor. Using TCP/IP to connect.
>The program is moving from the beginning of a million row
>table, opening and closing the cursor every time it wants
>a new row - it does not want every row. Bad code -
>DEFINATELY! But a re-write may not be a usable option.
>When I run my program locally (pointing to the database
on
>the server), it takes the same amount of time every time
>the cursor is opened. The ODBC DSN is defined locally.
>When I run the program directly on the server (same
>database), the amount of time to open the cursor gets
>progressivly worse. Almost as though on the server it is
>reading from the beginning of the table everytime, and as
>the program logically moves through the table. The ODBC
>DSN is defined on the server.
>.
>
Wednesday, March 7, 2012
Cube Processing Error - OLE DB error: OLE DB or ODBC error: Class not registered.
Problem
I get the above error when trying to process the cube.
Environment
Server OS - Windows 2003 64Bit
SQL Server 2005 64Bit
Database - Teradata
Connectivity - OLE DB for Teradata
Testing
- Have successfully tested OLE DB connectivity using Hyperion, connecting using an OLE DB Connection file.
- Get the same error when trying to process a sample MS Access database or Teradata
- Uninstalled and reinstalled SQL Server 2005
If anyone has any idea’s it would be greatly appreciated, thanks.
It might be that the provider (in the connection string of the datasource) is set to the 32bit version (if you used BI Development Studio or SQL Management Studio on a client 32bit machine). Then you deploy and, during processing, the AS2005 server tries to instantiate the provider and fails (because you have the 64bit version of the provider installed on the server machine).
Adrian
|||Thanks,
I used Visual Studio 2005 to develop a Test Cube on the Server after the installation.
Back Ground
I originally installed SQL Server 2005 using a Local Account but it was then decided that it was best done under a Domain account (Up until this point I could process AS2005 cubes). So I uninstalled SQL Server 2005 and reinstalled using the domain account.
I think somewhere along the way a Registry File has become corrupt. Is there any way to test this?
Next Step
If I am unable to resolve this issue I will re-image the server and hopefully this will remove any corrupt Registry files.
Any other Idea's?
Thanks
Tuesday, February 14, 2012
Crystl32.ocx with vb .net
I've created the report with Seagate crystal reports with the source to the database through a stored procedure (with ODBC). The stored procedure contains input parameter that I want to sent it to this report from .Net through Crystal report Control Crystl32.ocx.
I installed this control into .net but I don't how can I pass the parameter which I'm writing into textbox to report that contains stored procedure as a data source.
== Some code with Crystl32.ocx that I'm using to call the report:
With cr2
.ReportFileName = Application.StartupPath + "\klient_info.rpt"
.RetrieveDataFiles()
.DiscardSavedData = True
.ParameterFields(1) = "@.KlientID;" & TextBox2.Text & ";False"
.WindowState = crptMaximized
.Action = 0
End With
With the code above I'm passing into crytal report @.klientID - what I'm writting into textbox2. But the problem is that I don't want crystal report to prompt again for inserting input parameter.
Thanks,
ProBani.With the code above I'm passing into crytal report @.klientID - what I'm writting into textbox2. But the problem is that I don't want crystal report to prompt again for inserting input parameter.
are you sure that you only have one input parameter and that it is ParameterFields(1). My guess is that Crystal either expect another paramter or that the one your inputting isn't correct. That's why you get prompted to input another param.