Problem freeing resources used by SQLPrimaryKeys

Hello all,
First of all, I'm a little inexperienced with the odbc32.dll API's and
not too familiar with all the details of their usage. I have a list of
tables in the database and I'm iterating over that list and building
the primary key for each table. When I perform the iteration my
machine's memory usage spikes and the memory is never released (until
the program ends, of course). If I run the process several times the
memory usage becomes so high that the program crashes. I know that it's
not from creating objects in the application because I removed the code
that instantiates them and it still performed the same. Basically, I
reduced the algorithm to just the code that uses the odbc32.dll API's.
Below is the general code I'm using for each table in one iteration.
Can anyone tell me what I'm doing wrong and if there's any way to
correct it?
Thanks in advance,
Shannon
// Declare all the variables
res = SQLAllocEnv( ref env );
res = SQLAllocConnect( env, ref hdbc );
res = SQLConnect( hdbc.ToInt32(), dsnName, SQL_NTS, user, ( short
)( user == null ? 0 : user.Length ), pwd, ( short )( pwd == null ? 0 :
pwd.Length ) );
res = SQLAllocHandle( SQL_HANDLE_STMT, hdbc.ToInt32(), ref hstmt
);
res = SQLPrimaryKeys( hstmt.ToInt32(), null, SQL_NTS, schema, (
short )( schema == null ? 0 : schema.Length ), tableName, ( short
)tableName.Length );
res = SQLFetch( hstmt.ToInt32() );
while( res == 0 )
{
SQLGetData( hstmt.ToInt32(), 1, SQL_CHAR, szCatalog,
MAX_FIELDSIZE, ref lCatalog );
SQLGetData( hstmt.ToInt32(), 2, SQL_CHAR, szSchema,
MAX_FIELDSIZE, ref lSchema );
SQLGetData( hstmt.ToInt32(), 3, SQL_CHAR, szTableName,
MAX_FIELDSIZE, ref lTableName );
SQLGetData( hstmt.ToInt32(), 4, SQL_CHAR, szColumnName,
MAX_FIELDSIZE, ref lColumnName );
SQLGetData( hstmt.ToInt32(), 5, SQL_SMALLINT, szColumnSequence,
MAX_FIELDSIZE, ref lColumnSequence );
SQLGetData( hstmt.ToInt32(), 6, SQL_CHAR, szPKName,
MAX_FIELDSIZE, ref lPKName );
// Create application objects from primary key data
res = SQLFetch( hstmt.ToInt32() );
}
res = SQLCloseCursor( hstmt.ToInt32() );
res = SQLFreeHandle( SQL_HANDLE_STMT, hstmt.ToInt32() );
res = SQLFreeHandle( SQL_HANDLE_DBC, hdbc.ToInt32() );
res = SQLFreeHandle( SQL_HANDLE_ENV, env );
res = SQLDisconnect( hdbc.ToInt32() );Okay, after all the hair pulling, wouldn't it figure that the minute I
post a question I figure it out. In the cleanup process, I call
SQLFreeHandle on hdbc before I call SQLDisconnect on it. You must
disconnect first.

Problem deploying 2005 OLAP cube to same server

I have both limited hardware resources and the need to rebuild SQL 2005 OLAP cubes on the same server where they are being accessed. Because of the time needed to rebuild the cube it is preferable not to build it in place but, rather, to build it in another database and then backup/restore to the original location.

There doesn't appear to be a lot of documentation related to operating in this manner. The assumption appears to be that the cube structure will be deployed to another server or a backup is restored to its original location.

That works just fine except that when the underlying data structures (dimensions on which is it built) are changed it 'invalidates' both cubes. All of the objects (cube partitions and dimensions) are MOLAP which I thought made the entire cube structure 'stand alone'. If it is restored to a different physical server this problem does not occur.

Is it in some way considering the dimensions shared? Is there a setting or set of clean-up that needs to be done? Is there a different way to do this other than backup/restore?

Thanks in advance for any help that you could provide.

I am not very clear on what problems you mention you get after restoring the database on the same server under different name.
Try installing SP2 and see if that solves your problem.

Another approach is to install second instance of Analysis Server on the same machine and use it for processing only. This should both save you the hardware and provide level of separation you are trying to achieve.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.