Re: ADO Data Control = changing ConnectionString at runtime

Mark,

Thanks for your suggestion.

Ditching ADODC and writing my own looks to me like a huge undertaking. This
is a minor aspect of my overall program project. But, I commend you on your
work.

Jim

"Mark McGinty" <mmcginty@xxxxxxxxxxxxxxx> wrote in message
news:eyyiNtcDHHA.4612@xxxxxxxxxxxxxxxxxxxxxxx

"Jim Walsh" <JnospamWALSH@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23MTRC0PDHHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
I am using the ADO Data Control in a dialog box in an MFC-based
application
that I am developing using VS2005.

This application allows the user to select the database at run-time from
a
list of available databases whose structure is the same as the one that I
used in developing the application.

My problem: during development, I must set the ConnectionString property
of
the ADO control to my master copy of the database on my development
computer. It is my understanding that I will be able to modify that from
within my program at run-time. My class that controls the dialog box
includes a Cadodc member variable. I plan to use the
SetConnectionstring()
function of that member to change the connection string of the ADO
control
at run-time.

However, when the program runs, and the user brings up that dialog box, I
receive an error from that ADO control saying that it has an invalid
path.
This occurs during the Windows creation of the dialog window, and before
my
Cadodc control variable has had a chance to get connected with the
control,
and thus before I have had a chance to change the connection string.

I have tried setting the ADO Disabled property true at design time, but I
still get the error when the dialog box is being created at run-time.

I would appreciate any help in solving this problem.

The best solution to this problem is to ditch ADODC, and write your own
DataSource control/object. ADODC is, in a word, mega-lame, it is flawed
in ways too numerous to mention.

When I'm using Data Binding (which is practically the only use for a
DataSource object), and the schema of the table is known but the server is
a variable (nearly always the case) I like to code my DataSource controls
to initially load an xml-persisted zero-records copy of the recordset,
stored as a resource, and then connect-up to a database server as it
becomes available.

This strategy virtually eliminates data binding problems, the data is
always resolved instantaneously, there are never any network or security
obstacles to overcome, bindings are always intact, and I don't change to
the remote data source until I know that it's stable. (There is a method
of the DataSource interface, that notifies all consumers to refresh, it's
practically seamless.)

The downside is that it can be a bit tedious to maintain and test. I
always code the object to first look for an xml file in the CWD, which
makes it easier to change the schema, but it prone to accidentally
linking-in old version xml resources. Hmm, as I think, that's mostly a
VB problem, in VC you could make the .xml a dependency of the .res, and it
would recompile the resources any time the xml changed.

VB's whole build engine is weak -- it prompts with the common file dialog,
for the name of your build target, EVERY TIME you compile; worse yet, it
prompts you to overwrite every damn time, with 'No' as the default button,
no less! Worse yet, if yor're developing something that's loaded by
another process, like a COM object or DLL, and it failed to release your
binary, you have to manually kill the host process. And worst of all, VB
extensibility is all but freakin worthless -- wouldn't you logically have
to expect OnBeforeBuild, OnAfterBuild and OnBuildError events? They sure
would be useful, but they are conspicuously missing. You can initiate a
build in code, but that makes it a totally black box if anything goes
wrong, sooo... about the best I came up with was an AddIn button to
scratch the target and kill the host if needed -- but do you think VB
exposes any of its relevant project properties?

Figure it out, VB, it's a *build* *target*! Of course I want to overwrite
it, naturally anything standing in the way of that must die! It would be
pretty damn stupid to sit here coding ad infinitum if I had any qualms
with stamping over the top of old-version *compiler* *output* files...
What in hell were they thinking? <sigh> Anyways...

The upside of VB is that it makes creating DataSources pretty easy, I've
never created one in C++... closest I've gotten to data binding in a C++
project is regular old RFX.


-Mark


Thanks,
Jim







.