Articles - ODBC page 3

No, the Loser Doesn't Always Clean Up

In this case, you won.  And, you won big because the world of real SQL has just opened up before you.  Sure, if you want to be fancy and tricky you have to work hard, but isn't that true for everything?  Hehehe, shades of Dad revisited.

Back on Track

The Data Structure:


ID idStatementHandle;    /* use GENLNG for these*/
ID idConnectionHandle; 
ID idEnvironmentHandle;

Define your variables. . .get an hUser. . .

JDEBFRTN (ID) JDEBFWINAPI CloseTablesODBC (LPBHVRCOM lpBhvrCom, lpVoid, LPDSD55DRC lpDS) 
{
/************************************************************************
* Variable declarations
************************************************************************/
SQLHENV EnvironmentHandle = '\0'; 
SQLHSTMT StatementHandle = '\0';
SQLHDBC ConnectionHandle;
HUSER hUser;
ID idJDEDBReturn = JDEDB_PASSED;


/************************************************************************
* Check for NULL pointers
************************************************************************/
  /** common code removed to save space . . . . */
  /** Now get a hUser with InitBhvr. . **/ 
  /** Set error 078S if it fails  **/

Just like the last function, we have to get those memory pointers back, only this time we need to tell OneWorld to release the cross reference it's using to associate integers to our memory locations.  Well, thanks to JDE, one function does these two things for us: jdeRemoveDataPtr.  Look at the code below, it works just like jdeRetrieveDataPtr, but it also 'removes' OneWorld internal record of our memory pointer.


/************************************************************************
* Main Processing
************************************************************************/


StatementHandle =(SQLHSTMT *) jdeRemoveDataPtr(hUser,lpDS->idStatementHandle);
ConnectionHandle =(SQLHSTMT *) jdeRemoveDataPtr(hUser,lpDS->idConnectionHandle);
EnvironmentHandle =(SQLHSTMT *) jdeRemoveDataPtr(hUser,lpDS->idEnvironmentHandle);

Free the memory and Disconnect from the database.


SQLFreeHandle(SQL_HANDLE_STMT,StatementHandle);
SQLDisconnect(ConnectionHandle);
SQLFreeHandle(SQL_HANDLE_DBC,ConnectionHandle);
SQLFreeHandle(SQL_HANDLE_ENV,EnvironmentHandle);

 

Set the parameters to Zero just to be considerate and get out of Dodge.  You are done!


lpDS->idStatementHandle=0;
lpDS->idConnectionHandle=0;
lpDS->idEnvironmentHandle=0;
/************************************************************************
* Function Clean Up
************************************************************************/

return (ER_SUCCESS);

}

Conclusion

Well, we've gone a long way together and I hope you can see the potential this functionality has.  With true SQL capabilities you have no more limits in OneWorld, well potentially.  There are still some technical hurdles to overcome, but maybe your eyes are open now.

I'm not going to rehash all the statements of the introduction like a good conclusion does.  But, I will admonish you again in the strongest terms to look at the ODBC helps and samples that came with the MSVC compiler.  If you're at all intrigued by this primer I think you'll be amazed at all the neat things you can do with this stuff.  

With all that said, I'll wish you a hearty GOOD LUCK!

example graphic