MDI Project - Data best practices - query

MDI Project - Data best practices - query

Post by KB » Wed, 24 Jan 2007 07:24:34


I'm looking to rewrite a substancial existing MS Access/VBA app in VB
6, as a multiple document interface. I'm very solid in VBA in Access,
and refreshing myself in VB after a long time having only done simple
programs.

I'm looking for any advice given the information above. Best
practices, etc... before I go beyond exploratory, testing code.

After playing with ADOC I found I had terrible problems getting a
DBCombo to bind, and had success using the standard data control. So
I was thinking I'll have better luck with that. I'm using an access
flat file.

I'll be using a lot of forms having tabular data, with combo boxes in
the rows, linked to other data. My Access version has lots of forms
w/subforms with tabular data.

Since I'll be using a single mdb file, is there a methodology where I
can globally have the data control active at all time, and accessible
from any form? This of couse would simplify things, especially since
I was thinking of giving the user the ability to load, or close and
load another database.

thnx! Kevin
 
 
 

MDI Project - Data best practices - query

Post by KB » Wed, 24 Jan 2007 09:04:57

Arg! No combo's in grids without 3rd party control in VB6.

 
 
 

MDI Project - Data best practices - query

Post by KB » Wed, 24 Jan 2007 22:10:27


Thanks for the article. While it does look possible, there doesn't
seem to be a way to bind the combo box to a lookup table. I need to
use this is an order detail entry area, where users have a list of
products to choose from, and typing will auto-complete as I'm doing
now in Access.

thanks! Have to add that article to my links anyways....

On Mon, 22 Jan 2007 19:31:54 -0800, "Mark J. McGinty"
 
 
 

MDI Project - Data best practices - query

Post by Michael Co » Thu, 25 Jan 2007 08:01:40


OK, just looking at this post and other posts, my first suggestion would be
to not use data binding, but to code the database access yourself. Data
binding is frought with issues, and is very hard to debug.


--
Regards,

Michael Cole
 
 
 

MDI Project - Data best practices - query

Post by Mark J. Mc » Fri, 26 Jan 2007 06:25:39


I suspect most people that hold this view have never taken the time to to
understand data binding well enough to make it work. No, it is not a simple
as it's made out to be, if you need to do complex things -- but what is?

The weak link in data binding, as it was presented in VB6, was/is the data
source controls that were provided. DataEnvironment and ADODC are, imho,
unusable. The shame of it is that they did not spend the time to offer some
more substantial choices of data sources -- the template data source
basically gave you nothing, and there aren't a lot of workable examples.

The other shame is that negative opinions tend to snow-ball, because they
are so quickly and so readily spread.


-Mark
 
 
 

MDI Project - Data best practices - query

Post by Mark J. Mc » Fri, 26 Jan 2007 06:27:22


The included example project did exactly that -- it used a persisted
recordset instead of a 'live' one, but the concept is the same.


-Mark
 
 
 

MDI Project - Data best practices - query

Post by Ralp » Sun, 28 Jan 2007 01:25:20


simple
some

I agree that Data Binding is often dismissed too quickly.

I would even go one step further, and suggest that even the DE can used
productively for many client/server scenarios. Even offering abilities that
are not easy to do 'from scratch' - centralized queries and error handling,
and debugging Shape queries for example.

Creating your own Data Aware Classes is definitely the way to go. But as you
noted - few examples exist to aid a programmer when they first venture into
this world. Almost everyone has to go it alone with little more than blind
faith that it will be worth it in the end. Most give up and I don't blame
them. <g>

It doesn't help that all the microsoft examples generaly show "early data
binding", ie, the binding is setup using Property Settings during design
time - which always meant that any problems/errors were raised before a Form
was loaded. i.e. "it just blew up" and was hard for a beginner to figure out
what went wrong. <g>

-ralph
 
 
 

MDI Project - Data best practices - query

Post by Mark J. Mc » Wed, 31 Jan 2007 03:04:52

"Ralph" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

I don't blame them either, it's a lot of work! I also know it's a lot of
work to create meaningful examples of custom data controls, there's a very
fine line between trite/contrived and convoluted, that's difficult to find
before you've crossed way into the convoluted side. I've spent some spare
time trying to come up with something meaningful but not overkill to the
point it alienates beginning users... I have nothing to show for that time.
<shrug>


Indeed, and robust solutions are non-trivial.


-Mark