How to Open CRecordset for Insert

Steve Rodkey

unread,

Mar 28, 1997, 3:00:00 AM3/28/97

to

I have several applications were all I do is insert new records into the
database. I do this by making a CRecorset derived class, doing an Open,
AddNew, Update, Close. My question is what is the most efficient way to do
the open since I am not going to look at any of the data retrieved? Should
I just select everything or try to select something which would have only a
few matching records? Perhaps it makes no difference? My concern is that
as the database gets large, could the Open require a significant amount of
time since it is "selecting" records?

--
Steve Rodkey rod...@ziplink.net or s-ro...@ti.com

Don Reamey

unread,

Mar 31, 1997, 3:00:00 AM3/31/97

to

If all your going to do is insert new records, just create a database
object and call Execute() passing the insert statement.

Don

Dave Sinclair

unread,

Apr 1, 1997, 3:00:00 AM4/1/97

to

It may be a good idea to open the recordset with a where clause
that is never satisfied, i.e.. where 1=0,
as large result sets:

1) Slow your client app waiting for the return from open.
2) Eat server time, thus slowing everybody's client app.
3) Potentially de-cache useful stuff on the server by requiring
the build of temporary tables, thus slowing everything

Steve Rodkey <rod...@ziplink.net> wrote in article
<01bc3b7e$37433240$11fce8c7@steverhome>...

Tom Archer

unread,

Apr 1, 1997, 3:00:00 AM4/1/97

to

Just a thought... If you are not going to get any data back, why not use
the CDatabase::ExecuteSQL member function and format the "Insert" string
yourself using your data? That way you don't have to do CRecordset open at
all.

Tom Archer

Dave Sinclair <da...@lawsoft.co.uk> wrote in article
<01bc3eaa$bc6db4c0$LocalHost@LocalHost>...

Steve Rodkey

unread,

Apr 3, 1997, 3:00:00 AM4/3/97

to

The CRecordset does such a nice job of creating member variables which bind
to the fields. It makes the job easier and less error prone. Otherwise
why use the MFC stuff at all, just use the ODBC API The
CDatabase::ExecuteSQL does sound interesting, I must look into it.

--
Steve Rodkey rod...@aasp.net or s-ro...@ti.com

Tom Archer <tar...@attinview.com> wrote in article
<01bc3eb6$56a1de30$d69178cf@blondie>...

Tom Archer

unread,

Apr 4, 1997, 3:00:00 AM4/4/97

to

Hi Steve,

I agree that using the functionality provided by CRecordset is helpful
(time-saving) and less error prone. But, if you want to go that route, I
would agree with Dave Sinclair's advice of opening your CRecordset derived
class with a m_strFilter that you know will fail so that the open is not
too slow.

As far as doing the ExecuteSQL being the same as the ODBC API...no chance
;)!

ODBC API approach:
SQLAllocEnv, SQLAllocConnect, SQLSetConnectOption, SQLConnect,
SQLAllocStmt, SQLPrepare, SQLExecute, SQLFreeStmt, SQLDisconnect,
SQLFreeConnect, SQLFreeEnv.

About 100 lines of code with error checking!

MFC CDatabase approach:
CDatabase db;
db.Open(sDSN)
CString str = "Insert into Mytable...";
db.ExecuteSQL(str);
db.Close();

About 10 lines of code with error checking.

I would definitely not compare the two simply because you have to format
your own SQL string with CDatabase::ExecuteSQL

JMO,
Tom Archer

Steve Rodkey <rod...@ziplink.net> wrote in article

<01bc409a$29d5a5e0$4ef4f3ce@steverhome>...