i m developing a project on lib mang. through but i m facing some problems
such as i wanna how to call exe files of different SDI applications from any MDI application
please solve my queries.
tried to add new records through MFC:ODBC connectiviy. When I tried to add new records for "more" than 1 table at the same time in a mdb file, it say RecordSet is readonly exception. any idea or comments on how to solve this.
I want to Edit, Update some records in my ODBCDatabase? But I don't want to use Class Wizard. I connected My database, I accessed My database, I can read field's value but I don't know how to edit my recordset? Can you tell me the way to write this code? Thank you very much for your help.
Is there a way to avoid the ODBC dialog with the function open of Crecodset.
In a bucle, there is always an invocation to the function open of the crecordset, but when the link with the server is down, i need that the program does not show the message
"Connection failed...." and then, when click ok there is another message "sql server login".
Is there a way to avoid those messages and continue with the next line.
"Connection pooling is enabled before the environment is allocated by calling SQLSetEnvAttr to set SQL_ATTR_CONNECTION_POOLING to SQL_CP_ONE_PER_DRIVER (which specifies a maximum of one pool per driver) or SQL_CP_ONE_PER_HENV (which specifies a maximum of one pool per environment). SQLSetEnvAttr in this case is called with EnvironmentHandle set to null, which makes the attribute a process-level attribute. If SQL_ATTR_CONNECTION_POOLING is set to SQL_CP_OFF, connection pooling is disabled."
Now I am a little confused about the handle to the environment. Here the author allocates a handle to an environment:
srRetCode = SQLAllocHandle( SQL_HANDLE_ENV, NULL, &m_shSQLEnv ); // Get Global Handle
So the program stores this handle in m_shSQLEnv. But from what I have read MFC uses it's own environment and the only way to get at the handle to the environment is to call AfxGetHENV().
According to the on-line help:
"HENV AFXAPI AfxGetHENV( );
The handle to the ODBC environment currently in use by MFC. Can be SQL_HENV_NULL if there are no CDatabase objects and no CRecordset objects in use.
You can use the returned handle in direct ODBC calls, but you must not close the handle or assume that the handle is still valid and available after any existing CDatabase- or CRecordset-derived objects have been destroyed."
This handle is automatically allocated in CDatabase::AllocConnect() and is then stored in m_henvAllConnections which is a member of an _AFX_DB_STATE object. This source code can be found in dbcore.cpp.
So although this may indeed enable Connection Pooling is it really safe to use the m_shSQLEnv member variable for anything at all? I think not. However removing the allocation of the environment and the associated member variable from this example should go a long way toward enabling Connection Pooling.
If you are using the latest ODBC Administrator version 3.510.xxx (which comes with Visual Studio 6.0), there is a Connection Pooling property page which allows you to configure the pooling time out.
All you need to do is call the database the normal way (without having to specify connection pooling) and the ODBC administrator will actually handle the connection pooling for you. There is also a Perfmon enable button which if enabled will allow you to monitor the database connection using Perform Monitor.
Many moons ago, before ATL (or too early to use ATL), my company had some engineers that decided to write an IIS DNA application. They used the CDatabase classes to write all of the ActiveX scriptable components on the IIS server side. Not a bad idea considering they were leveraging existing MFC technology and it was a fast way to ramp up the application development time (everyone was MFC savvy).
Once the application was finished, there was a major flaw in it that we only found out after we released it to the general public (it scaled horribly) because:
A.) ODBC Connection Pooling wasn't implemented, and isn't not possible with CDatabase within MFC Active Components.
B.) the MFC components where "blocking" in the IIS request queue would "lunch line" every thread (the apartment model was in fact STA, but it appeared that MFC had too much blocking code to be consdered a scalable component architecture)
It took us 6 months to re-architect and re-write the damn thing to get it straight. We learned a lot, but this was between 1998 and 1999--on the cusp of the ADO/ATL convergance--so we were living the "bleeding edge" sort to speak.
It's my opinion that the ONLY way to go with database programming these days is ADO and ATL. Using CDatabase on the client is ok, I guess, but NEVER use this on the server... please, learn from our mistakes. It was ugly.
Connection pooling is supported as a "no brainer" with ADO and ATL, so the hoops you have to jump through just aren't there...