List:MySQL ODBC« Previous MessageNext Message »
From:Peter Carter Date:June 29 1999 10:42pm
Subject:RE: VB, MyODBC, MySQL problems
View as plain text  
At 11:45 AM 6/29/99 -0700, you wrote:
>Excellent!  I was trying to get through there yesterday, but something was
>broken.  I ran your wizard thingie and the output's pretty interesting.

YOYO FreeBSD/MySQL due to overheating...... problem solved ;)

>Seems, though, that you're still not really taking full advantage of ADO, as
>far as the idea of a recordset entry with all selected fields available
>automagically, with semi-automatic updates and such.  This is basically a
>class providing a nice wrapper around straight SQL stuff...

The object was to create a consistant interface for any object. MySQL is
not the only target and VB is not going to be the only code generated. VBS
is about half done and then I will be on to C++.

My connector of choice is RDO, as it is much cleaner and leaner. I put the
ADO support in due to licence restrictions of RDO. If I let ADO go on
autopilot, I would run into the same problems as everyone else and be as
consistant as the version numbers. I like stability. I have plans to write
a native VB driver for MySQL, so I must also leave the door open for that
as well.

>...that said, however, it does look like much of what's in there I can
>reuse, in "simpler" configurations (my model doesn't really require a
>consistent open connection--I just do a query--process--close, or an update
>of a single field).  Also, you gave me a much faster, fairly
>complete-looking escape function.

Check out the function 'DBClose'. This effictively allows you to keep your
recordset, close the connection and re-open on demand. The advantage here
is that you do not have to re-select. There is even a hook for a whatch-dog
for idle applications.

>How would you recommend storing large blocks of text (in my case, HTML code
>generated by the MS DHTML widget, in all its microsoft bloated html code
>glory)?  You've got both a "put literal" function (doing the escaping bit
>for special chars) and a "put binary" function, for turning everything into
>pure hex bitstreams.  I can see the appeal of the latter, but you have some
>warnings in your code about buffer sizes and such... Which approach is
>likely to be "best" (easiest, fastest, least trouble)?  If the binary
>method, could you help me out a little with those warnings? (what do I have
>to watch out for, etc.)?

The reason I use both, is that some data types can not accept a binary hex
equivalent. I found the escapes just did not work properly due to os
conversions, lack of adiquite documentation and version issues. If you look
at the MySQL docs, they list more escapes than are actually supported. You
will be lucky to find them at all in the M$SQL docs.

If you use TEXT type for the html code, use the deliminators. It's just
faster. If you are concerned about conversion errors, use the hex approach.
If you are using the VARCHAR or CHAR types, I do not think you can use hex
at all? (Maybe this is M$....)

Buffer sizes are important. However, my updates chunk the data. This means,
with stock buffers, they will be properly stored. You may have to open them
up to read all the data though.

My choice is based on the use.

Steel all the code you want. I designed it to DO and TO LEARN. If you can
find a better / faster way to do the job, let me know...... ;)

Peter B. Carter (peterc@stripped)
Pager: 613-751-4660

Flames are a waste of cyberspace, don't bother.......

VB, MyODBC, MySQL problemsDavid Schuetz28 Jun
  • RE: VB, MyODBC, MySQL problemsPhillip Grant28 Jun
  • Re: VB, MyODBC, MySQL problemsPeter Carter2 Jul
RE: VB, MyODBC, MySQL problemsDavid Schuetz28 Jun
RE: VB, MyODBC, MySQL problemsDavid Schuetz29 Jun
  • RE: VB, MyODBC, MySQL problemsPeter Carter2 Jul