|
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.  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.
|
|
|
|
|
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?
|
|
|
|
|
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 
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
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.
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 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.
|
|
|
|
|
For bookmarks, this link has the info: CRecordset::SetBookmark[^]
I've never heard of the CQueryDef class
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);
...
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?
|
|
|
|
|
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..." 
|
|
|
|
|
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
|
|
|
|
|
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! 
|
|
|
|
|
|
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. Just another day in the life of a geek, eh?
|
|
|
|
|
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.
I appreciate all the help, man. And if you're ever headed to Atlanta, be sure to throw a guitar in with your bags.
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Christopher Duncan wrote: Hey, I may have to come to SoCal just to party!
Never need an excuse to do that around here
|
|
|
|
|
|
OLE DB is my preference.
Steve
|
|
|
|
|
Do you happen to know if there's a performance difference between dao, oledb and the CDatabase stuff?
|
|
|
|
|
Sorry, can't help you there. DAO is old and your best off not using it if possible. ODBC is the industry standard but can be accessed via OLD DB. OLE DB is very flexible, COM based and gives you the most options.
Steve
|
|
|
|
|
That's cool. I appreciate the help, man.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
