Re: Creating a report entirely through code

From: Marshall Barton (marshbarton_at_wowway.com)
Date: 03/15/04 

Date: Mon, 15 Mar 2004 10:11:44 -0600

Marco Castro wrote:

>I do backup the front-end before making any changes. I never knew that
>there was an official term and procedure for it tough. Copy and paste
>always worked great for me.

That's good, and Copy/paste is a convenient way to
copy/backup a file.

Other than "Good Practices", I don't think there is an
"official" term for individual styles of software design and
implementation (although some people have applied a name to
a specific set of techniques).

> I'm not sure why you're fighting this issue so
>much. In my case this is a very simple database, it doesn't have any
>complicated procedures or modules anywhere in it.

I'm not trying to fight anything here. I'm just trying to
pass on some of the things I've learned over the years.
You said yourself somewhere else in this thread that
self-modified code is not a good idea.

> Apart from some out of
>the ordinary reports everything in it was done using the built in wizards.
>I'm not even sure why you would use access if you wanted to create something
>more complicated, for anything like that we use mysql and build specific
>applications for those databases with .net. It doesn't take that much
>longer then trying to build it through access and since were not limited by
>the functionality of access we can build a better interface for the user. I
>would prefer it if we could do this for all of our databases but with
>something as simple as what I'm working with right now it really wouldn't
>make any sense. Still I'm not an access expert by any means and I've seen
>people build allot of impressive databases with it. Just work with what you
>know I guess.

I guess it's just part of human nature to prefer the tools
you already know how to use. 

-- 
Marsh
MVP [MS Access]
>"Marshall Barton" wrote:
>>
>> >I'm not sure what you mean by "developer's backup procedures, awareness
>of
>> >corruptions".
>>
>> Maybe you don't do it, but most developers backup the front
>> end mdb file before making any significant change (including
>> modifying code modules, forms or reports.  These are large
>> objects that require a lot of manipulations in the mdb file,
>> thus greatly increase the probability of corruption.  When
>> you're working in the database making these kinds of
>> changes, you start to notice the little signs that some kind
>> of a corruption has started to occur (e.g. the compile
>> button doesn't gray out after a compile, a control starts to
>> behave in a funky way, etc).  You are in then in a position
>> to take immediate remedial actions.
>>
>> When you use code to make design changes in a running
>> application, users are unaware of these symptoms and will
>> thrash around trying to finish their job until the
>> application crashes and, more often than not, don't have a
>> recent backup to get them back up and running.
>>
>>
>> >Are you worried that it could corrupt the data in the database?  It
>> >shouldn't be a problem in this case since I'm using this for creating a
>> >report and not a form where they have to enter data in.  I'm actually
>just
>> >using labels for the entire thing.
>>
>> No, I'm worried about the module, form and report objects
>> being corrupted.  Presuming that you follow good design
>> practices, your data is in a backend mdb file and should be
>> safe from this kind of issue.
>>
>>
>> >I thought about using TC's approach but I found it to be to limiting.  My
>> >problem is that each of the columns in the report has to be read from a
>> >database.  So if I create 10 invisible labels for the records what
>happens
>> >when they add a new column in and there aren't enough labels for each of
>the
>> >columns?  I know that it would be really easy to go in and add another
>label
>> >but I'm the only one in the company that would know how to do that.  If I
>> >ever leave they would be out of luck.  The way I've created it now they
>can
>> >add as many columns as they want and it will always work.
>>
>> Not a good reason.  If you think they might have 10 fields
>> in the report, precreate 40 or 60 invisible controls.
>> Generally, the width of the paper is a limit on how many
>> fields a report can reasonably display so I generally use
>> that as a guidline.
>>
>> All of the things you can do after using CreateControl can
>> be done (and more easily) by setting control properties on
>> an existing control.
>>
>>
>>
>> >Marshall Barton wrote:
>> >> PMFJI, but this is a terrible idea.  You would not be
>> >> creating controls at runtime, you would be switching into
>> >> design time activities in the middle of a running
>> >> application.  This will open the door for all of the things
>> >> that can go wrong during application design without the
>> >> safety of the developer's backup procedures, awareness of
>> >> corruptions and application bloat.
>> >>
>> >> You should seriously reconsider using TC's approach.
>