Re: Porting VC++ 6.0 / DAO to VS2003 - what's the best non .NET db API? - C / C++ / MFC Discussion Boards

Hello,

I have two document templates and through a menu option I want to open a new document of one document type through a menu option which is not File New option.How do I do it.

How to divert a message handler to CWinApp class instead of CView? ANd how do I pass parameters to CDocument class from CWinApp to initialize CDocument class.

Thanks
Prithaa.

When a web server sends a response that does not contain a Content-Length: header, and is not chunked, how is a application supposed to know when it has finished downloading the complete document?

The response headers give no clue how big the file is, so how does one know?

The web server is not closing the connection, BTW. So I need to avoid blocking.

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Never mind, I found out how. When the document is done, the recv() function returns ZERO bytes received.

Thanks for reading my post!

--------------------------------

"All that is necessary for the forces of evil to win in the world is for enough good men to do nothing" -- Edmund Burke

Hey, guys.

My concert lighting app has been on the back burner for several years now. Having reached the point where I'm ready to start designing the lighting for my current show, I naturally found a few tweaks I wanted to make to the software. Tried to build it in VS 2003 and got a lot of whining about DAO being deprecated, and recalled that MFC is hard wired to DAO 3.5 (which the compiler also isn't liking). So, I guess I need to rewrite the db code. D'Oh! | :doh:

Not what I had in mind when I opened the lid on this thing.

This is a standalone MFC app talking to a local Access db, and since it involved realtime control of moving lights, performance is a consideration. The current code is using the CDatabase / CRecordset approach. Since Microsoft has kicked DAO to the curb, I'm wondering what db technology I should port this to. I absolutely do not want to drag the .NET framework into the app.

Is there a new set of database access classes that plays nice with Access that are non .NET? I'd appreciate any suggestions you guys might have as it's currently dead in the water.

By the way, looked at the ADO forum, but it seems to be mostly SQL related topics. What I need is help porting an app to whatever non .NET API is appropriate for MFC.

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

The ODBC classes are similar if not identical. If performance is an issue (it's unlikely ODBC is
noticeably faster or slower than DAO) then caching performance-critical data in RAM is the
way to go.

I'm curious (since I've been a musician forever) how are you interfacing to hardware?

Mark

Hey, Mark.

Thanks so much for the quick reply. Regarding the app, I'm controlling the lighting via the standard DMX protocol that concert lighting speaks. I'm using a printer port dongle (they have cat5 devices these days) from www.artisticlicence.com[^]for the DMX. The app also speaks MIDI and plays CD & wav audio via DirectX. Believe it or not, all this for bar band shows - 10,000 watts of mostly Martin lighting.

Now that you mention it, I poked around in the code (haven't been in this stuff for several years now), and see that there's both a CDaoDatabase & CDatabase. Hopefully, it'll just be a matter of some global search & replace stuff and a little bit of setup on an ODBC connection. Any gotchas that come to mind?

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Sounds fun! A previous band I played with dragged lights around for a while. I always thought
it would be fun to do a PC interface for them but I never got around to it Smile | :)

Christopher Duncan wrote:
Any gotchas that come to mind?

I've only used the ODBC (non-dao) classes but from what I understand they are very similar.
No gotchas I can think of except perhaps the database connection itself. Make sure you have a
later version of MDAC (there's all kinds of versions) and the latest ODBC driver for Access.
That will save any immediate trouble. VS2003 can generate CRecordset classes for all your tables
if you have a database to connect to. I imagine you could do that with DAO as well Smile | :)

I use these classes pretty much every day on VS2003 so if something comes up I'll try and help
out.

Mark

I used to do gigs hauling around a bunch of par cans, but these moving lights really up the bar on things. Of course, you just haven't lived until you've experienced a bug in your code while controlling a room full of these things. Quite exciting. Smile | :)

I took the quick & dirty approach and did a global replace of CDao to C, and that's getting me in the right direction. The two main obstacles I'm looking at presently are these.

First, I use CDaoRecordset::GetLastModifiedBookmark() all over town in the scenario where I'm adding a new record and then need to access the record I just added, e.g.

CWaitCursor ThinkWeBetterWaitTillTommorrow;<br />
try<br />
{<br />
	FormatTextAndName();<br />
// CDesignTimeEventSet derived from CDaoRecordset<br />
	CDesignTimeEventSet setDesignTimeEvent;<br />
	setDesignTimeEvent.Open();<br />
	setDesignTimeEvent.AddNew();<br />
	setDesignTimeEvent.m_lType = eImageEventPlayCd;<br />
	setDesignTimeEvent.m_strName = m_strName;<br />
	setDesignTimeEvent.m_strEventData = m_strEventData;<br />
	setDesignTimeEvent.Update();<br />
	setDesignTimeEvent.SetBookmark(setDesignTimeEvent.GetLastModifiedBookmark());<br />
	m_lDesignTimeId = setDesignTimeEvent.m_lId;<br />
	setDesignTimeEvent.Close();<br />
}<br />
catch(CException* pe)<br />
{<br />
	pe->ReportError();<br />
	pe->Delete();<br />
}

What's the preferred method of doing this when using CRecordset rather than CDaoRecordset (the former doesn't have this function)?

Secondly, I make significant use of CQueryDef to execute various query & non query operations, e.g.

CQueryDef defTruss(&g_dbCurrent);<br />
CString strQuery = "";<br />
strQuery.Format("DELETE * FROM PatternStep WHERE DesignTimePattern = %ld", m_lPatternId);<br />
defTruss.Create(NULL, strQuery);<br />
defTruss.Execute();<br />
defTruss.Close();

What class would you use in the CDatabase world?

Really appreciate the help, man.

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

For bookmarks, this link has the info: CRecordset::SetBookmark[^]

I've never heard of the CQueryDef class Smile | :)

I do direct queries through a CRecordset-derived class object (which represents a table).
There's a wizard to create these classes quickly from an existing database. The wizard-created
class has member variables for each column in the table, which are automagically filled with
the data for the current row as you scroll through result sets.

Something like:

pPatternStepTable = new CPatternStepTable(pDB); //pDB is a CDatabase (or derived) pointer
...
CString strQuery = "";
strQuery.Format("DELETE * FROM PatternStep WHERE DesignTimePattern = %ld", m_lPatternId);
pPatternStepTable->Open(CRecordset::dynaset, strQuery, CRecordset::executeDirect);
pPatternStepTable->Close();

Since these classes wrap the ODBC APIs, you also have the flexibility of making native calls
like this:

HSTMT hStmt;
::SQLAllocHandle(SQL_HANDLE_STMT, pDB->m_hdbc, &hStmt);
nSqlRet = ::SQLExecDirect(hStmt, (SQLTCHAR *)(const TCHAR *)strQuery, _tcslen(strQuery));
...etc.

Turns out that CDatabase has an ExecuteSQL(LPCSTR) method that handles the CQueryDef functionality, so I'm covered there.

I'd already looked at the SetBookmark help. The reason I was using the bookmark code was due to the fact that after you call CDaoRecordset::Update() the object no longer pointed to the record just updated. In other words,

// member variable in a given class
CRecordset m_rs;

m_rs.AddNew();
m_rs.SetSomeMemberVariables("record 42");
m_rs.Update()
// m_rs no longer points to "record 42"

Using GetLastModifiedBookmark(), I could set the current bookmark to the record just updated. Now I have no way of doing this.

How does CRecordset behave after a call to Update()? If it doesn't point to the record just updated, how do you get it back?

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

I'm pretty sure it still points to the record. You'd have to call CRecordset::Edit, make any
column changes and call Update again to edit the record after using AddNew/Update. If you close
the query, though, you'll have to use a bookmark or some other way to obtain the record again.

Note that on CRecordset::Open, you'll want to use the appropriate option flags (CRecordset::appendOnly
to just add new records, CRecordset::readOnly if you are just going to read records, etc.).
Using CRecordset::none allows you to edit, addnew, and delete records.

Most excellent, thanks. Nine gazillion compiler errors later, I'm finally down to linking.

You know, most days like this start with the phrase, "All I wanted to do was..." Roll eyes | :rolleyes:

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Christopher Duncan wrote:
You know, most days like this start with the phrase, "All I wanted to do was..."

My all time favorite was porting my product (a bunch of GUI/Service apps, a couple shared DLLs)
to Unicode.
Or was it converting from Borland's OWL to MFC heh Smile | :)

Of course, after the OWL rewrite, for the first time in history Borland tried to look like Microsoft instead of the other way around. I still raise a glass to Phillipe Khan every now and then, as I learned to program on Turbo C 1.0 (the only thing I could afford back in my broke musician days).

After chasing down a bit of excitement due to the fact that CRecordset tends to throw exceptions where CDaoRecordset didn't (and cleaning up numerous warnings from sloppy coding that VC 6 didn't whine about), I'm up and running with VS2003. Although I really didn't have any desire to move it away from VC 6, I'm glad I did now as I remember having to do some hacks because of the hardwired DAO version stuff with MFC. With the ODBC recordset approach, it's more portable to the future.

Just wanted to pop in and say thanks very much for your help. If you feel like talking music, etc., hit the email link and I'll reply back with my real address. Always good to meet another brother in arms! Big Grin | :-D

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Awesome! That was relatively painless (especially for me haha). I bet 2003 is going to be much
nicer to work with. Smile | :)

Christopher Duncan wrote:
Of course, after the OWL rewrite, for the first time in history Borland tried to look like Microsoft instead of the other way around.

Yeah. I'm still not sure who tried to look like who. I started (C programming) with Turbo C as
well, and it was a faster more reliable compiler at the time. I was very active in OWL user
groups because I knew the code intimately. The only article I've ever had published was on OWL
Doc/View architecture Laugh | :laugh:

. I was approached to write an OWL sockets class but at that time
Borland engineers were jumping ship and going to Microsoft. WHen I was forced to move to MFC I
was amazed how similar the frameworks were. I had alot of code to migrate and it was tedious but
really none of the logic had to change. Just new macros, function definitions, and startup code
for the most part. Anyway, ever since then I've wondered who tried to look like who Smile | :)

Maybe
they were both written by the same people...

I'll fire an email your way!

Take care,
Mark

Mark Salsbery wrote:
That was relatively painless (especially for me haha).

No doubt.

I'd been doing MFC since VC 1.0 came out, and had also been doing a little of Borland's Windows stuff in Windows 3.1. I seem to recall that they skipped a major version number, and then the next one that came out was essentially MFC. Don't know why they went that route. Borland was always the leading edge of cool development environments. However, that release was pretty much the beginning of the end for them. Quality and market share continued to slip until they became irrelevant. Man, do I miss those guys.

The ODBC based CRecordset stuff turned out to be an absolute freakin' nightmare. Bizarre exceptions thrown, stuff worked in debug but would crash in release, yada, yada. I finally figured out how to get the CDaoRecordset stuff compiling again, got rid of my hacks from previous versions, and it works again. There's a few days of my life I won't get back. Roll eyes | :rolleyes:

Just another day in the life of a geek, eh? Big Grin | :-D

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Christopher Duncan wrote:
The ODBC based CRecordset stuff turned out to be an absolute freakin' nightmare. Bizarre exceptions thrown, stuff worked in debug but would crash in release, yada, yada

That's a bummer! Sorry I steered you in a bad direction. Apparently the two are not as similar
as I thought.

Cheers,
Mark

You steered me in a perfectly valid direction! It's not your fault that the quality of Microsoft products is, er... inconsistent. Roll eyes | :rolleyes:

I appreciate all the help, man. And if you're ever headed to Atlanta, be sure to throw a guitar in with your bags. Big Grin | :-D

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Christopher Duncan wrote:
And if you're ever headed to Atlanta, be sure to throw a guitar in with your bags.

I'm a drummer, but I'll bring a guitar. I know 2 or 3 chords Laugh | :laugh:

Mark Salsbery wrote:
I'm a drummer, but I'll bring a guitar. I know 2 or 3 chords

Well, I can beat on things but they're usually computers, so quite the pair we'll make. Laugh | :laugh:

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Well, like a studio owner/engineer once said to me..."You can't break rock-n-roll"!

It's better that I bring sticks instead.

I'm in Southern California so if you're out this way and need to jam...!

Hey, I may have to come to SoCal just to party! I need to hit the left coast to hassle Tom in Redmond anyway and collect on some of the pizzas he owes me. Big Grin | :-D

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

Christopher Duncan wrote:
Hey, I may have to come to SoCal just to party!

Never need an excuse to do that around here Smile | :)

Author of
The Career Programmer and Unite the Tribes
www.PracticalStrategyConsulting.com

OLE DB is my preference.

Steve