Cursor taking longer to open at every open

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.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.
>.
>

Current Time

Hi. I have a critical design issue. Not a regular time dimension case.

i work for a set of schools where each school academic has a different academic calendar. say some schools start in august, others in september.. i generated the date keys per school to populate the time dimension. so my time dimension looks like this:

DATE_KEY,

DATE_SCHOOL,

DATE_DATE,

DATE_YEAR,

DATE_MONTH,

DATE_WEEK,

DATE_DAY_NUMBER,

DATE_FISCAL_ACAD_YEAR,

DATE_FISCAL_TERM, DATE_FISCAL_WEEK,

DATE_FISCAL_WEEKDAY_NUMBER,

DATE_FISCAL_ACAD_YEAR_DAY_NUMBER,

DATE_HOLIDAY, (y/n)

DATE_WEEKEND, (y/n)

DATE_DAY_NAME,

DATE_FISCAL_TERM_FIRST_DAY,

DATE_FISCAL_TERM_LAST_DAY,

DATE_FISCAL_WEEK_FIRST_DAY,

DATE_FISCAL_WEEK_LAST_DAY

I need help in finding a design to get the current term/current week/current day so that a school manager would get his current's school week's data or term data when he logs in to the system.

Thanks

Could it be that there are only a few sets of dates applicable? In which case you could create Calendars listing the relevant dates and link this back to the school.|||

I added fields to the schools dimension stating the current acad year, term,week,and day per school. and these fields are to be updated at each ETL process. I will use them in the queries.

thanks