Hello all,
I have one chance to get this right, as I'm nearing a release of a program.
I've looked at the database settings, and so far, have set the following:
* Unchecked 'Enable design changes for tables in datasheet view'
* Unchecked 'Check for truncated number fields' (I would prefer the user NOT
see #### in fields or columns that they shrink too far)
* Unchecked 'Track Name AutoCorrect Info'
* Set all Tables to 'SubDatasheet = None' (BTW, I read to never use Auto...
What about setting the subdatasheet to the correct table, instead of auto??
Setting's I'm not sure about:
* Remove personal information from file properties on save. ( I would think
I would want my company to show in the file properties, but maybe not other
personal details, etc.)
* Compact on Close. I assume this only works for the program mdb file, and
would not work on the back-end database? Might not be a bad idea to set this
for the program mdb file. Anyone have experience with this setting?
Also, I would imagine that items under the Advanced tab are not for the
current database, things like OLE/DDE timeout, Refresh interval, etc.
Any other items I should set for the current database?
Many Thanks,
Andy
49  2658 
Hi, Andy.
* Set all Tables to 'SubDatasheet = None' (BTW, I read to never use
Auto... What about setting the subdatasheet to the correct table, instead
of auto??
That's not quite as slow as Auto, but it can severely slow your database
application. Don't use subdatasheets.
* Remove personal information from file properties on save. ( I would
think I would want my company to show in the file properties, but maybe
not other personal details, etc.)
Then just leave what you want others to see. Microsoft Office records the
information you gave when you installed it on your hard drive (that's why
you see your company name and other such data in the Database Properties),
and automatically places it in the Database Properties when the file is
created, so it's best to check that information before distributing the
file.
* Compact on Close. I assume this only works for the program mdb file, and
would not work on the back-end database?
It works on the Jet database file that has been opened via the Access GUI
(interface). Any Jet database file that is only opened by merely linking to
the tables it holds cannot make this setting apply to _that_ database. And
it's not a good idea to use "Compact on Close" in a multiuser database,
anyway. Compact it periodically when the users aren't in it.
Also, I would imagine that items under the Advanced tab are not for the
current database, things like OLE/DDE timeout, Refresh interval, etc.
Why not?
Any other items I should set for the current database?
Ensure Option Explicit is set in the Declarations area of every module,
"Require Variable Declaration" is checked, "Compile on Demand" is not
checked, "Allow Design Changes" is set to "Design View Only" in all forms,
and only allow one form view in each form (unless it's really, really
necessary to have more than one form view setting.
It's best to have custom menus instead of the built-in menus so that you
control what the users do when using the application. It's also usually
best to convert to an MDE and distribute the MDE database file, not the MDB
database file (but ensure that you keep a copy of the MDB file to easily
make design changes or upgrades to future versions later).
There are a few more settings to check, but I can't think of them right now.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Thanks, Gunny!
Can you think of any pitfalls with allowing the program mdb file to be
compacted on close? This would seem a good idea, in theory, as the program
file wouldn't severely inflate over time.
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote in
message news:nf8Li.3$n92.1@trnddc06...
Hi, Andy.
>* Set all Tables to 'SubDatasheet = None' (BTW, I read to never use
Auto... What about setting the subdatasheet to the correct table, instead
of auto??
That's not quite as slow as Auto, but it can severely slow your database
application. Don't use subdatasheets.
>* Remove personal information from file properties on save. ( I would
think I would want my company to show in the file properties, but maybe
not other personal details, etc.)
Then just leave what you want others to see. Microsoft Office records the
information you gave when you installed it on your hard drive (that's why
you see your company name and other such data in the Database Properties),
and automatically places it in the Database Properties when the file is
created, so it's best to check that information before distributing the
file.
>* Compact on Close. I assume this only works for the program mdb file,
and would not work on the back-end database?
It works on the Jet database file that has been opened via the Access GUI
(interface). Any Jet database file that is only opened by merely linking
to the tables it holds cannot make this setting apply to _that_ database.
And it's not a good idea to use "Compact on Close" in a multiuser
database, anyway. Compact it periodically when the users aren't in it.
>Also, I would imagine that items under the Advanced tab are not for the
current database, things like OLE/DDE timeout, Refresh interval, etc.
Why not?
>Any other items I should set for the current database?
Ensure Option Explicit is set in the Declarations area of every module,
"Require Variable Declaration" is checked, "Compile on Demand" is not
checked, "Allow Design Changes" is set to "Design View Only" in all forms,
and only allow one form view in each form (unless it's really, really
necessary to have more than one form view setting.
It's best to have custom menus instead of the built-in menus so that you
control what the users do when using the application. It's also usually
best to convert to an MDE and distribute the MDE database file, not the
MDB database file (but ensure that you keep a copy of the MDB file to
easily make design changes or upgrades to future versions later).
There are a few more settings to check, but I can't think of them right
now.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
On Sep 29, 1:13 am, "ARC" <PCES...@PCESoft.invalidwrote:
Thanks, Gunny!
Can you think of any pitfalls with allowing the program mdb file to be
compacted on close? This would seem a good idea, in theory, as the program
file wouldn't severely inflate over time.
All kinds of things can happen with end users. Compact on close means
that the mdb is always undergoing maintenance every time you close the
mdb. And if for any reason Windows does not behave itself, your end
user will ring you up asking why there is a file called database1.mdb
and why the thing has stopped working.
Not something I would do.
HTH
Ananda
Hi, Andy.
Can you think of any pitfalls with allowing the program mdb file to be
compacted on close?
Well, the user has to wait every time he closes the database for it to
compact and then quit. That's just a minor inconvenience. But since no
else is sharing the front end in a properly split database, the users won't
be attempting to compact while other users are still using the file, and
thereby creating all those db1.mdb, db2.mdb, db3.mdb FOD in the directory.
This would seem a good idea, in theory, as the program file wouldn't
severely inflate over time.
What have you got in the front end that needs to be compacted every time the
database file is opened? The non-static data should be in the back end,
which should be compacted periodically. The front end's file size should
remain relatively the same size once application development has stopped.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Hey Gunny,
I've looked everywhere under the Access options in 2007, and I can't find
the following two:
"Require Variable Declaration" is checked, "Compile on Demand" is not
checked..
Did 2007 do away with these settings?
Thanks!
Ok, you DON'T want to use the option to "remove personal information from
file prop's on save". When you enable this option, exiting the program takes
a very long time...just an fyi
Hi, Andy.
I've looked everywhere under the Access options in 2007, and I can't find
the following two:
"Require Variable Declaration" is checked, "Compile on Demand" is not
checked..
Did 2007 do away with these settings?
Nah. They're in the VB Editor's "Options" side of the house. Press
<ALT><F11to open the VB Editor. Select the Tools -Options... menu. See
the "Editor" and "General" tabs for those two options. (I'm going from
memory here, from nearly 1 1/2 years ago when I last used Access 2007 Beta
2, so please speak up if I'm wrong.)
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
They're there, many thanks!
Any theory on why not to check teh "Compile on Demand" option?
Thanks, Gunny,
Andy
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:nf8Li.3$n92.1@trnddc06:
Don't use subdatasheets.
Unless you need them.
(they are actually quite handy, especially for a form with subforms
where it's useful to view the main form as a data sheet -- in that
case, you can have continuous forms embedded in the equivalent of a
continuous form, something's that's impossible with plain old forms)
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:nf8Li.3$n92.1@trnddc06:
It works on the Jet database file that has been opened via the
Access GUI (interface). Any Jet database file that is only opened
by merely linking to the tables it holds cannot make this setting
apply to _that_ database. And it's not a good idea to use
"Compact on Close" in a multiuser database, anyway. Compact it
periodically when the users aren't in it.
I don't think COMPACT ON CLOSE is viable in any scenario, because
it's not cancellable. I have seen too many cases where a corrupted
MDB lost data when it was compacted. Without a backup, if your
database compacts automatically, you could lose valuable data that
might be recoverable before the compact.
So, I see this as one of those "features" that seems like a good
idea until you actually think it through. And I *never* use it, and
won't use it with any of my clients' apps.
And, of course, as you say, in any properly-designed app, all that
gets compacted is the front end, which oughtn't need to be compacted
at all.
So, it's a useless feature most of the time, and the rest of the
time, it's dangerous.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:nf8Li.3$n92.1@trnddc06:
Ensure Option Explicit is set in the Declarations area of every
module, "Require Variable Declaration" is checked, "Compile on
Demand" is not checked,
These are all in the VBE options (something that always trips me up,
as I still frequently program in A97).
It's best to have custom menus instead of the built-in menus so
that you control what the users do when using the application.
I disagree with this. It depends on the application and the users. I
have only ever had two apps with custom menus/toolbars, and they
were a pain to work with (I eventually set it up so that when I was
working both the custom and standard toolbars displayed).
It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"ARC" <PC*****@PCESoft.invalidwrote in
news:WR****************@nlpi069.nbdc.sbc.com:
Can you think of any pitfalls with allowing the program mdb file
to be compacted on close?
Yes. Some corrupted databases will lose data after a compact (that's
why when you're trying to repair a corrupted database, you always do
it on a copy. Right?). If compact on close is ON, then you get no
chance to make your backup and could lose data that might otherwise
be recoverable from the uncompacted corrupted database.
This would seem a good idea, in theory, as the program
file wouldn't severely inflate over time.
It's a terrible idea. No properly-designed Access app is distributed
as anything but a split app, and no properly-designed front end ever
grows enough to warrant compacting.
Secondly, constant compacting can be a performance drain, because a
compact flags every saved query for recompiling the next time it
runs. This means you *never* get the benefit of precompilation in
queries.
You're right that it sounds like a good idea, but whereas it's
mostly useless, it's also in some cases dangerous.
Don't use it.
Ever.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196. 97.142...
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:nf8Li.3$n92.1@trnddc06:
>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
I always distribute the front end as an MDE. It adds a level of security
and control, that you don't get with an MDB. There is no reason not too.
Steven
I second that! If you're working for a company and just distributing an app
in-house, you could use the .mdb, but if you're distributing an app
globally, .mde is the way to go.
"Steve" <st***@nospam.netwrote in message
news:bJ*************@newsfe12.lga...
>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196. 97.142...
>"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:nf8Li.3$n92.1@trnddc06:
>>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
I always distribute the front end as an MDE. It adds a level of security
and control, that you don't get with an MDB. There is no reason not too.
Steven
"Steve" <st***@nospam.netwrote in
news:bJ*************@newsfe12.lga:
>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196. 97.142...
>"'69 Camaro"
<Fo**************************@Spameater.orgZERO_S PAMwrote in
news:nf8Li.3$n92.1@trnddc06:
>>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
f
This is another piece of common wisdom that I ignore. I've only
one case where I make sure the user has an MDE, and that's
because she has a tendency to type through the occasional
unhandled error message. Thus, I never hear about the error (she
didn't see it), and I end up being called in to revert the code
she typed into to its compilable state. So, she gets an MDE. All
my other users have MDBs, and it's Just Fine.
I always distribute the front end as an MDE. It adds a level of
security and control, that you don't get with an MDB. There is no
reason not too.
There are plenty of reasons not to:
1. inability to fix a bug over the phone without sending a new
update, or having the end user edit the MDB and generate a new MDE.
If you've got the MDB on the other end already, you haven't got too
much security.
2. supporting multiple versions of Access. In that case you have to
generate multiple MDEs, one for each version, and that's more
trouble than it's worth.
What kind of security do you think an MDE gets you?
"ARC" <PC*****@PCESoft.invalidwrote in
news:n9*****************@newssvr17.news.prodigy.ne t:
I second that! If you're working for a company and just
distributing an app in-house, you could use the .mdb, but if
you're distributing an app globally, .mde is the way to go.
What do you mean "globally?" Sure, if I were writing a downloadable
app to distribute over the Internet, but I don't do that, and my
clients are trustworthy (they aren't going to "steal" my code). I
don't think it's worth the trouble in the environment in which my
apps are used.
That doesn't mean your environment isn't different. I'm just
pointing out that not everyone believes that MDEs are a requirement.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"Sure, if I were writing a downloadable
app to distribute over the Internet"
That's exactly what I do, and what I meant by globally.
Take care, David. Your replies have helped a lot on many of my other posts.
I'm working this weekend on finally getting my commercial app released as a
beta to about 20 beta-testers. Re-doing my app in Access 2007 has been the
most difficult project I've ever done.
If your interested in seeing (or even testing? <grina 2007 production app,
let me know.
Andy
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"ARC" <PC*****@PCESoft.invalidwrote in
news:n9*****************@newssvr17.news.prodigy.ne t:
>I second that! If you're working for a company and just
distributing an app in-house, you could use the .mdb, but if
you're distributing an app globally, .mde is the way to go.
What do you mean "globally?" Sure, if I were writing a downloadable
app to distribute over the Internet, but I don't do that, and my
clients are trustworthy (they aren't going to "steal" my code). I
don't think it's worth the trouble in the environment in which my
apps are used.
That doesn't mean your environment isn't different. I'm just
pointing out that not everyone believes that MDEs are a requirement.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
On Sat, 29 Sep 2007 16:36:28 -0500, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:
>"Steve" <st***@nospam.netwrote in
news:bJ*************@newsfe12.lga:
>>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196 .97.142...
>>"'69 Camaro"
<Fo**************************@Spameater.orgZERO_ SPAMwrote in
news:nf8Li.3$n92.1@trnddc06:
It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
f
This is another piece of common wisdom that I ignore. I've only
one case where I make sure the user has an MDE, and that's
because she has a tendency to type through the occasional
unhandled error message. Thus, I never hear about the error (she
didn't see it), and I end up being called in to revert the code
she typed into to its compilable state. So, she gets an MDE. All
my other users have MDBs, and it's Just Fine.
I always distribute the front end as an MDE. It adds a level of
security and control, that you don't get with an MDB. There is no
reason not too.
There are plenty of reasons not to:
1. inability to fix a bug over the phone without sending a new
update, or having the end user edit the MDB and generate a new MDE.
If you've got the MDB on the other end already, you haven't got too
much security.
2. supporting multiple versions of Access. In that case you have to
generate multiple MDEs, one for each version, and that's more
trouble than it's worth.
What kind of security do you think an MDE gets you?
I think there are pros and cons to each. I usually distribute MDE
format apps. They generally connect to a db server. After the user
logs in, the first thing the app does is a version check. If I want
to distribute an update, I simply change the version number in the
database, the user is informed that an update is available and the app
downloads its own update. There's actually a range of allowed
versions, so I can make the update mandatory or optional. I've been
doing this for years with excellent results. I couldn't very well do
the same thing with an MDB.
Just my 2cents worth
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in
news:Xn**********************************@216.196. 97.142:
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
I can't recall ever delivering an mde or ade. I believe people should get
what they pay for, and be able to see it, and if they want, screw around
with it, too. I have not included the secrets of nuclear fission nor the
location of my cache of AK 47's in any of my code, and so am quite
unconcerned that anyone may steal my "secrets", all of which I'm willing
to give away anyway.
With that goes a a belief that people should be responsible for what they
do. Screw up the application? Pay me or someone else to repair it.
Since 1992 or whatever I've delivered a lot of Access applications. Has
this style ever bit me? Nope! Now Aim Mail ... oops that's another sad
story outlined in my new sig lines.
--
lyle fairfield
Think free Aim Mail is a good deal? 4 gig storage! IMAP too! I have an
account. It has about two thousand messages stored on Aim's server. But I
can't access the account, nor the stored messages nor new messages. Do I
have the username and password right? I'm pretty sure because I can log
into the account with an instant message program like Miranda or Trillian
(AIM too). And they can tell me I have fifteen new e-mails. But for two
weeks I can't login with the webmail interface, nor with IMAP, nor with
POP. So, be careful with Aim mail. Cuz there seems to be no recourse.
And, yes, I know the terms I agreed to specify AOL has no responsibility
whatever. But maybe this will help you remember those terms are for real
and your e-mail may disappear forever.
Hi, David.
>It's best to have custom menus instead of the built-in menus so
that you control what the users do when using the application.
I disagree with this. It depends on the application and the users. I
have only ever had two apps with custom menus/toolbars, and they
were a pain to work with
Providing custom menus allows the developer to control what the users can do
and when they can do it. Most Access developers want the users to stay out
of the places that will compromise their hard work and carefully designed
database application. And many Access users often claim they want fewer
menu choices, not more. (Essentially, just the ones they need.) The whole
complement of menu built-in choices tends to confuse new and beginning
Access users.
Besides, providing custom menus makes the application appear to be a
custom-built software application (which it is), not a cookie-cutter Access
database template.
(I eventually set it up so that when I was
working both the custom and standard toolbars displayed).
That's what I do, too.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Hi, David.
>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
One of the best reasons to distribute an MDE database file is to ensure that
the VBA code remains compiled, which keeps code execution time at optimimum
speed. One reason I like distributing MDE's is because users can't
accidentally mess with the VBA procedures and then call me for free tech
support when their ill-thought out changes have messed up the program. It's
very difficult for them to accept the idea that I can't give endless hours
of free tech support for years and years after I've developed, designed, and
delivered the original program, and if the customer wants additional,
bug-free features, then that requires a fee for a consultant's time. Since
I generally distribute both the MDB and the MDE to the customer, if they
want to make changes to the MDB, then that's fine with me, because I've only
been paid to support the MDE database file, and that's the only one I'll fix
bugs on for free.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Gunny,
Totally with you on your last 2 posts. In Acc97, I used custom toolbars,
mostly for datasheets, and for notes fields. With the standard Copy/Paste,
Sort ascending / descending, remove filter/sort, etc. However, it appears
to be different in Access 2007. Any datasheets have automatic filtering and
sorting options at the top, which is very nice. There's many things about
2007 that will dramatically cut down coding time.
By the way, I am curious as to how you find your business customers for
custom programming work? I would assume that they would be small business,
sole proprietorships, etc.?
I finally released my commercial app last night, as a beta, in access 2007
(spent 2 solid days wrestling with Wise, and the new scripts, etc). So when
I finally finish this project, doing custom work for small business would be
interesting. For my commercial app, I've basically been working on the same
program since 1998, and to say it gets monotonous would be an understatement
(However, access 2007 actually breathed new life into my development of the
program, as I was definetely burned out before that).
One thing I really like about Acc2007 is the look. The ribbon menus are a
steep learning curve, but the look of them is well worth the effort. And
actually, strange as it sounds, it's not just the look, it seems to have a
better "feel" as well. I received e-mails a time or 3 from prospective
customers asking when I would freshen the look. With the new one, I will
definetely NOT here that complaint.
Take care, Gunny.
Andy
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote in
message news:0vMLi.472$ht5.58@trnddc02...
Hi, David.
>>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only one
case where I make sure the user has an MDE, and that's because she
has a tendency to type through the occasional unhandled error
message. Thus, I never hear about the error (she didn't see it), and
I end up being called in to revert the code she typed into to its
compilable state. So, she gets an MDE. All my other users have MDBs,
and it's Just Fine.
One of the best reasons to distribute an MDE database file is to ensure
that the VBA code remains compiled, which keeps code execution time at
optimimum speed. One reason I like distributing MDE's is because users
can't accidentally mess with the VBA procedures and then call me for free
tech support when their ill-thought out changes have messed up the
program. It's very difficult for them to accept the idea that I can't
give endless hours of free tech support for years and years after I've
developed, designed, and delivered the original program, and if the
customer wants additional, bug-free features, then that requires a fee for
a consultant's time. Since I generally distribute both the MDB and the
MDE to the customer, if they want to make changes to the MDB, then that's
fine with me, because I've only been paid to support the MDE database
file, and that's the only one I'll fix bugs on for free.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Hi, Andy.
By the way, I am curious as to how you find your business customers for
custom programming work? I would assume that they would be small business,
sole proprietorships, etc.?
I find business customers by word-of-mouth. Do a great job, and the
customer is likely to forget about you as soon as the job is done, because
you did what he expected. Do a great job -- and something spectacular, and
he'll likely remember you next time someone else is in need of your
expertise and will recommend your name. Hand out lots of business cards to
your current customers so that they can hand them out to others when the
need arises.
I would assume that they would be small business, sole proprietorships,
etc.?
Almost never. The small business owners are the ones who need cheap Access
database applications built by competent Access developers the most, but
they're the ones with the least IT knowledge. They haven't got a clue how
to program or design a database application or how much work it involves, so
they hire you to do it for them. You know how to do it. Therefore, it
_must_ be easy, and if it's that easy, it's not worth paying much for. "I
can hire a high school student to do that for cheaper!" Go ahead. He needs
to learn how to do it, so hire him to learn how for you. ;-)
Nearly all of my customers have been large corporations and government
contractors.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Hi, Andy.
However, it appears to be different in Access 2007.
Uh-huh. Access 2007 is very different from earlier versions.
I finally released my commercial app last night, as a beta, in access 2007
(spent 2 solid days wrestling with Wise, and the new scripts, etc).
Good for you! Good luck with the sales on that.
For my commercial app, I've basically been working on the same program
since 1998, and to say it gets monotonous would be an understatement
(However, access 2007 actually breathed new life into my development of
the program, as I was definetely burned out before that).
It must be very complex by now if you've been working on it consistently for
nine years!
One thing I really like about Acc2007 is the look. The ribbon menus are a
steep learning curve, but the look of them is well worth the effort.
Access 2007 isn't quite as delightful for most developers as it is for
users. The improvements were definitely aimed at the Excel user crowd to
draw new customers from that arena.
I received e-mails a time or 3 from prospective customers asking when I
would freshen the look. With the new one, I will definetely NOT here that
complaint.
Be prepared to trade that complaint for others, such as "Why did you change
it? It was great the way it was!" :-)
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"ARC" <PC*****@PCESoft.invalidwrote in
news:pN****************@newssvr17.news.prodigy.net :
By the way, I am curious as to how you find your business customers
for custom programming work? I would assume that they would be small
business, sole proprietorships, etc.?
Shudder!
--
lyle fairfield
Think free Aim Mail is a good deal? 4 gig storage! IMAP too! I have an
account. It has about two thousand messages stored on Aim's server. But I
can't access the account, nor the stored messages nor new messages. Do I
have the username and password right? I'm pretty sure because I can log
into the account with an instant message program like Miranda or Trillian.
And they can tell me I have fifteen new e-mails. But for two weeks I can't
login with the webmail interface, nor with IMAP, nor with POP. So, be
careful with Aim mail. Cuz there seems to be no recourse. And, yes, I know
the terms I agreed to specify AOL has no responsibility whatever. But maybe
this will help you remember those terms are for real and your e-mail may
disappear forever.
Hi, Andy.
The challenge has been to make everything optional.
I can see how that would be a challenge with so many features!
Do you think a call for beta-testers would be appropriate for a new topic
on this newsgroup? I could use the help for sure.
Absolutely. But be aware that not that many people are using Access 2007
yet, and of those who do, not everyone has the time or inclination to be a
good beta tester. So you may not get that many responses here, but if you
don't put the word out, you won't find new people willing to be beta
testers.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Thanks, Gunny. I finally got the install working late last night, so it will
install the access 2007 runtime, so that version of access is not required.
And I'm using the Sagekey script, so it will co-exist with other versions
(and not put up the "configuring access" or "finishing installation" repair
message when you switch versions).
This is, by far, the most difficult development project I've ever done. In
addition to reworking in Acc2007, I did a complete re-design of the
interface. What I used to do was to have one Mainmenu form, with a header
area for customer select, then a subform: Submenu. In the submenu, I would
shuttle in and out the main screens. So if the user was on the customer
screen, and switched to the quotes screen, I would load the quote form into
the submenu of the mainmenu form (but keep it customer-drive, so the screens
would follow along with the customer selected in the header). With the
tabbed interface option of Access 2007 (and with the bugs it had where you
couldn't use certain menus on lower subforms, such as the popup for rich
text), I decided to make each form self-contained, and did away with the
mainmenu. The benefits are the user can have Customers, Quotes, Parts all
open at once. But the drawback was I had to change every query, and every
bit of code that pointed to Forms!Mainmenu!submenu.form...And almost
everything referenced mainmenu in some way. Yikes! It was well worth the
effort, as I think this will lead to a better program.
I had a few posts on importing strategies, and this was a very difficult
task. The old back end db had no relationships, enforcement of referential
integrity, etc. So in my import utility program, I had to do about 30-40
validation checks of the old database, and even prompt for the user to
select missing customer id's, part id's, etc., that were orphaned. If
orphaned data is found, I put up a form with the mismatched data. They can
either choose the missing custID, partID, etc., or update all missing items
to a single id (archive customer, or part, etc.). I had customers send their
db's for testing, and kept adding new validation checks as they came up.
Finally have it down where I haven't seen an error in db tries lately.
What a challenge this has been! Still sane so far...I need to make a post
thanking everyone in this group, because I'm not sure I could have done this
without you!
Andy
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AMwrote in
message news:wmQLi.504$ht5.428@trnddc02...
Hi, Andy.
>The challenge has been to make everything optional.
I can see how that would be a challenge with so many features!
>Do you think a call for beta-testers would be appropriate for a new topic
on this newsgroup? I could use the help for sure.
Absolutely. But be aware that not that many people are using Access 2007
yet, and of those who do, not everyone has the time or inclination to be a
good beta tester. So you may not get that many responses here, but if you
don't put the word out, you won't find new people willing to be beta
testers.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Arch <se*****@spam.netwrote in
news:18********************************@4ax.com:
I think there are pros and cons to each. I usually distribute MDE
format apps. They generally connect to a db server. After the
user logs in, the first thing the app does is a version check. If
I want to distribute an update, I simply change the version number
in the database, the user is informed that an update is available
and the app downloads its own update. There's actually a range of
allowed versions, so I can make the update mandatory or optional.
I've been doing this for years with excellent results. I couldn't
very well do the same thing with an MDB.
Er, why not?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:3iMLi.471$ht5.242@trnddc02:
Hi, David.
>>It's best to have custom menus instead of the built-in menus so
that you control what the users do when using the application.
I disagree with this. It depends on the application and the
users. I have only ever had two apps with custom menus/toolbars,
and they were a pain to work with
Providing custom menus allows the developer to control what the
users can do and when they can do it.
Sure, but my users never use the default menus, and they do use some
of the default toolbars (like filtering, for instance). They follow
the logic of the app through the command buttons given them on the
forms I write, and hardly ever have reason to venture outside that.
Most Access developers want the users to stay out
of the places that will compromise their hard work and carefully
designed database application.
Me, too. And I've never had any problems with it.
And many Access users often claim they want fewer
menu choices, not more. (Essentially, just the ones they need.)
My users don't touch the menus.
The whole
complement of menu built-in choices tends to confuse new and
beginning Access users.
Mine ignore them entirely.
Besides, providing custom menus makes the application appear to be
a custom-built software application (which it is), not a
cookie-cutter Access database template.
Ny users don't seem to give a rat's ass.
>(I eventually set it up so that when I was
working both the custom and standard toolbars displayed).
That's what I do, too.
It does cause problems when keyboard shortcuts are used in both the
custom menus/toolbars and the default ones (and I use the keyboard
shortcuts all the time, so this is an annoyance).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:0vMLi.472$ht5.58@trnddc02:
Hi, David.
>>It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
This is another piece of common wisdom that I ignore. I've only
one case where I make sure the user has an MDE, and that's
because she has a tendency to type through the occasional
unhandled error message. Thus, I never hear about the error (she
didn't see it), and I end up being called in to revert the code
she typed into to its compilable state. So, she gets an MDE. All
my other users have MDBs, and it's Just Fine.
One of the best reasons to distribute an MDE database file is to
ensure that the VBA code remains compiled, which keeps code
execution time at optimimum speed.
Uh, if you deliver an app that doesn't decompile, it won't decompile
even if it's an MDB.
One reason I like distributing MDE's is because users can't
accidentally mess with the VBA procedures and then call me for
free tech support when their ill-thought out changes have messed
up the program.
My users don't muck with the VBA code. They don't know to. It has
saved me a lot of time being able to fix their MDB with a phone call
(when I don't have remote access) and walking them through the fix
over the phone. Saves them money, too.
In the case of the user who was typing in the code, her company got
charged for the time it took to fix (because she was ignoring error
messages that should have been reported so that I could fix them),
and she ended up with an MDE (the only user of that app with an MDE;
and, yes, it's a pain because of that).
It's
very difficult for them to accept the idea that I can't give
endless hours of free tech support for years and years after I've
developed, designed, and delivered the original program, and if
the customer wants additional, bug-free features, then that
requires a fee for a consultant's time.
My clients don't expect me to fix their bugs for free nor to fix
things they've broken themselves for free. I don't know what kind of
clients would expect that.
Since
I generally distribute both the MDB and the MDE to the customer,
if they want to make changes to the MDB, then that's fine with me,
because I've only been paid to support the MDE database file, and
that's the only one I'll fix bugs on for free.
I know all the reasons for distributing an MDE and did so for a
while in the late 90s. But it was more trouble than it was worth for
most of my clients so I don't do it much any more.
It certainly isn't a requirement.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Hi, Andy.
And I'm using the Sagekey script, so it will co-exist with other versions
(and not put up the "configuring access" or "finishing installation"
repair message when you switch versions).
That's a blessing. Everyone else is going out for a coffee break every time
they switch back to Access 2007.
This is, by far, the most difficult development project I've ever done.
I don't doubt it!
The old back end db had no relationships, enforcement of referential
integrity, etc.
Sooner or later, you'll pay the price with orphan records when referential
integrity is not enforced. The sooner it is, generally the easier it is to
fix. It's best to enforce referential integrity between related tables at
the very beginning of development and never relax that enforcement.
What a challenge this has been! Still sane so far...I need to make a post
thanking everyone in this group, because I'm not sure I could have done
this without you!
We wish you much success!
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
"'69 Camaro" <Fo**************************@Spameater.orgZERO_SP AM>
wrote in news:MnPLi.317$0I5.228@trnddc08:
>I would assume that they would be small business, sole
proprietorships, etc.?
Almost never. The small business owners are the ones who need
cheap Access database applications built by competent Access
developers the most, but they're the ones with the least IT
knowledge. They haven't got a clue how to program or design a
database application or how much work it involves, so they hire
you to do it for them. You know how to do it. Therefore, it
_must_ be easy, and if it's that easy, it's not worth paying much
for. "I can hire a high school student to do that for cheaper!"
Go ahead. He needs to learn how to do it, so hire him to learn
how for you. ;-)
Nearly all of my customers have been large corporations and
government contractors.
This exactly the opposite of my experience. 90% of my clients are
small businesses and they are perfectly happy to pay to have a
competent programmer create and maintain their Access apps. Most of
them are people who have been burned in the past by a database
developeer who sold them a project on the cheap, and it either never
worked at all, or never quite did what it was supposed to do.
Because of that, when they come to me, they are almost always ready
to pay what is necessary to get what they really need, and recognize
that it takes a lot of time and effort and plenty of interaction
with the developer.
It also helps that I provide all their IT support, since it makes it
easier for me to take a holistic approach to their problems. And
they quickly come to understand that I understand the big picture,
because I talk to them about their 5-year IT budget, what they need
to replace when, how they can most efficiently spend their IT
dollars, and how their database application relates to the general
IT infrastructure.
I have no difficulty keeping the customers for whom I'm sole IT
support person. And they are great clients, because, being small
businesses, they know the importance of being paid promptly (unlike
large companies which increasingly are taking 60 to 90 days to pay
invoices).
Some of my worst experiences have been with large companies. Two of
them abandoned the project at the 2/3s completion point, in fact,
and the only reason in both cases was a change of personnel in
management who no longer saw the importance of the project or didn't
like the direction it was going. I hate the waste of effort and
money that was involved (particularly since one was the NY affiliate
of a large, nationally-known non-profit organization).
So, we all have very different experiences, I think, and different
practices apply in different situations.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
I'm definetely enforcing RI now, hence the difficulty of the import utility,
and have removed all the .ocx's, save the treeview control one. I found
other code very helpful just the other day, as I removed the MSOutl12.OLB
file from references.
Thanks again,
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196. 97.142...
Arch <se*****@spam.netwrote in
news:18********************************@4ax.com:
>I think there are pros and cons to each. I usually distribute MDE
format apps. They generally connect to a db server. After the
user logs in, the first thing the app does is a version check. If
I want to distribute an update, I simply change the version number
in the database, the user is informed that an update is available
and the app downloads its own update. There's actually a range of
allowed versions, so I can make the update mandatory or optional.
I've been doing this for years with excellent results. I couldn't
very well do the same thing with an MDB.
Er, why not?
I, too, would like to know, as I have done this with MDB client applications
to server databases as far back as Access 2.0, and with split Access/Jet
databases since Access 97 without any problems.
Larry Linson
Microsoft Access MVP
And, my experience is a blend -- one client for whom I did a lot of work in
the late 1990s (I was a subcontractor to the prime contractor on the
project) was a Fortune 100 company, and I have had several clients where the
application was used just by one person (or just one person at a time)...
and all levels in between. Our job for the Fortune 100 company was for a
single department, their corporate real estate department, which was
modest-sized, and several users at each of three major real estate firms to
which they had outsourced day-to-day operations, and had 100+ additional
internal users of that database in many, many departments and locations on
their corporate WAN, who viewed and reported data, but rarely entered any.
Most of my work has been with local firms, but not all on-site, and some has
been remote (including one modestly-small subcontract with David Fention --
he was easy to work for and I learned some new approaches to different kinds
of problems).
When I began working with Access, I got most of my work through contract
broker / recruiting firms, but over time, ended up with nothing but
direct-to-client work through word of mouth and referrals. That's not to say
I would not sub-contract again if the occasion arose... I still have a
retail (direct-to-client) rate and a wholesale (subcontract) rate.
Larry Linson
Microsoft Access MVP
On Mon, 01 Oct 2007 02:13:08 GMT, "Larry Linson"
<bo*****@localhost.notwrote:
>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196 .97.142...
>Arch <se*****@spam.netwrote in
news:18********************************@4ax.com :
>>I think there are pros and cons to each. I usually distribute MDE
format apps. They generally connect to a db server. After the
user logs in, the first thing the app does is a version check. If
I want to distribute an update, I simply change the version number
in the database, the user is informed that an update is available
and the app downloads its own update. There's actually a range of
allowed versions, so I can make the update mandatory or optional.
I've been doing this for years with excellent results. I couldn't
very well do the same thing with an MDB.
Er, why not?
I, too, would like to know, as I have done this with MDB client applications
to server databases as far back as Access 2.0, and with split Access/Jet
databases since Access 97 without any problems.
Larry Linson
Microsoft Access MVP
I don't wish for the user to be able to modify the source code.
Principally the version stamp.
Hi, David.
Uh, if you deliver an app that doesn't decompile, it won't decompile
even if it's an MDB.
Access 2003 has a bad habit of becoming decompiled. I've seen it happen
when the user moves the library database file, and I suspect it happens
after certain Windows updates have occurred. And the users have
occasionally typed inside code modules and then saved their edits, which
decompiles the code. I've found it easier just to give them an MDE database
file to avoid this problem.
My users don't muck with the VBA code.
I wish I had your users! There's always seems to be some joker in the bunch
here who thinks he knows how to code and can save the expense of hiring a
consultant.
My clients don't expect me to fix their bugs for free nor to fix
things they've broken themselves for free. I don't know what kind of
clients would expect that.
Clients we'd rather some other consultant supported. ;-)
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com http://www.Access.QBuilt.com/html/ex...ributors2.html for contact
info.
Arch <se*****@spam.netwrote in
news:df********************************@4ax.com:
On Mon, 01 Oct 2007 02:13:08 GMT, "Larry Linson"
<bo*****@localhost.notwrote:
>>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.19 6.97.142...
>>Arch <se*****@spam.netwrote in
news:18********************************@4ax.co m:
I think there are pros and cons to each. I usually distribute
MDE format apps. They generally connect to a db server. After
the user logs in, the first thing the app does is a version
check. If I want to distribute an update, I simply change the
version number in the database, the user is informed that an
update is available and the app downloads its own update.
There's actually a range of allowed versions, so I can make the
update mandatory or optional. I've been doing this for years
with excellent results. I couldn't very well do the same thing
with an MDB.
Er, why not?
I, too, would like to know, as I have done this with MDB client
applications to server databases as far back as Access 2.0, and
with split Access/Jet databases since Access 97 without any
problems.
I don't wish for the user to be able to modify the source code.
Principally the version stamp.
I don't wish for my clients to do either of those things either.
And they don't.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Thanks for the explanation.
Access security, despite the fact that it is breakable, would be better for
preventing users from changing code. In the last year or so, there have
been reports of software that can reconstruct source from "compiled MDE
code". But, for the "typical user," using an MDE should accomplish the
purpose, and might be somewhat easier.
Good luck with your application and best wishes for a successful completion.
Larry Linson
Microsoft Access MVP
"Arch" <se*****@spam.netwrote in message
news:df********************************@4ax.com...
On Mon, 01 Oct 2007 02:13:08 GMT, "Larry Linson"
<bo*****@localhost.notwrote:
>>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.19 6.97.142...
>>Arch <se*****@spam.netwrote in
news:18********************************@4ax.co m:
I think there are pros and cons to each. I usually distribute MDE
format apps. They generally connect to a db server. After the
user logs in, the first thing the app does is a version check. If
I want to distribute an update, I simply change the version number
in the database, the user is informed that an update is available
and the app downloads its own update. There's actually a range of
allowed versions, so I can make the update mandatory or optional.
I've been doing this for years with excellent results. I couldn't
very well do the same thing with an MDB.
Er, why not?
I, too, would like to know, as I have done this with MDB client
applications
to server databases as far back as Access 2.0, and with split Access/Jet
databases since Access 97 without any problems.
Larry Linson
Microsoft Access MVP
I don't wish for the user to be able to modify the source code.
Principally the version stamp.
Thanks, Larry! The beta was a bit rough, so I'm working on beta-2.. Word to
the wise, avoid ever using a treeview control if you can...
On the plus side, a beta tester reported that it installed with flying
colors on vista! Never a small feet...
Andy
"ARC" <PC*****@PCESoft.invalidwrote in
news:_x*****************@nlpi069.nbdc.sbc.com:
On the plus side, a beta tester reported that it installed with
flying colors on vista! Never a small feet...
Well, you know what they say about small feet...
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Never heard that one, something related to programming, I take it?? lol
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@216.196. 97.142...
"ARC" <PC*****@PCESoft.invalidwrote in
news:_x*****************@nlpi069.nbdc.sbc.com:
>On the plus side, a beta tester reported that it installed with
flying colors on vista! Never a small feet...
Well, you know what they say about small feet...
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"ARC" <PC*****@PCESoft.invalidwrote in message
news:sA***************@newssvr19.news.prodigy.net. ..
>I think part of the problem is I'm using the access 97 version of the
active x control with access 2007.
The one time I tried to use the newer .ocx, I was getting errors on the
node statmeents, so I went back to the 97 version. A previous post
suggested I try removing all tree view's, compact my db, then add it in
using the 'add active x control' option. That seems to have gotten rid of
the error. So I plan on replacing all with the newer .ocx, mscomctl.ocx, I
believe. I'm going to create another install after I do this, and see if
my testers have better luck with the control.
My use was with Access 2003, I just used what was current, and it worked as
advertised. I'm sure you can do more with it than I did, but it did what my
client wanted. That's the only time since I've been doing Access work that
a client asked for functionality, and then specified the Control they wanted
used to do it. But, before the project really got off the ground, it was
interrupted, and their interest never came back.
Larry
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"Steve" <st***@nospam.netwrote in
news:bJ*************@newsfe12.lga:
There are plenty of reasons not to:
1. inability to fix a bug over the phone without sending a new
update, or having the end user edit the MDB and generate a new MDE.
If you've got the MDB on the other end already, you haven't got too
much security.
2. supporting multiple versions of Access. In that case you have to
generate multiple MDEs, one for each version, and that's more
trouble than it's worth.
What kind of security do you think an MDE gets you?
1) I never allow my clients to go in and change code (unless the client is
using there own IT group to maintain and support the applications). What a
potential nightmare. I also sell an Access based application, and maintain
one code base. I make the fixes, and send the frontend. It automatically
attaches to the backend database (no big deal).
2) I have no problem generating seperate MDEs for different versions of
Access from one MDB. Not a big deal. For the above application, the code
base is maintain in Access 97. I generate an Access 97 MDE, Access 2003 MDB
and MDE.
3) The lack of full-proof MDE security issue is a bogus issue. It prevents
the client from messing with the source code, and provides some level of
security (not great, but better than nothing). Hey, I lock the door of my
house when I leave, even though it is not to tough to break in. Why make
stealing more tempting and easier?
I guess if I had many small clients with many different small applications,
the MDE thing could be a pain. But that is not my business.
"Steve" <st***@nospam.netwrote in news:fF***********@newsfe12.lga:
>
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
>"Steve" <st***@nospam.netwrote in
news:bJ*************@newsfe12.lga:
There are plenty of reasons not to:
1. inability to fix a bug over the phone without sending a new
update, or having the end user edit the MDB and generate a new
MDE. If you've got the MDB on the other end already, you haven't
got too much security.
2. supporting multiple versions of Access. In that case you have
to generate multiple MDEs, one for each version, and that's more
trouble than it's worth.
What kind of security do you think an MDE gets you?
1) I never allow my clients to go in and change code (unless the
client is using there own IT group to maintain and support the
applications). What a potential nightmare.
None of my clients have ever once attempted to intentionally alter
code, except for the clients I was collaborating with (i.e., they
did hired me to enhance the application that they had written and
were continuing to work on).
I also sell an Access based application, and maintain
one code base. I make the fixes, and send the frontend. It
automatically attaches to the backend database (no big deal).
I don't see any of this as relating to the topic of "security."
2) I have no problem generating seperate MDEs for different
versions of Access from one MDB. Not a big deal. For the above
application, the code base is maintain in Access 97. I generate
an Access 97 MDE, Access 2003 MDB and MDE.
Do you automate it?
3) The lack of full-proof MDE security issue is a bogus issue. It
prevents the client from messing with the source code,
Which is only an issue for people who have the class of client for
whom that's a realistic risk -- in my 10+ years of professional
Access development, I've never had such a client.
and provides some level of
security (not great, but better than nothing). Hey, I lock the
door of my house when I leave, even though it is not to tough to
break in. Why make stealing more tempting and easier?
I just don't see delivering an MDE as a security issue unless:
1. you have passwords embedded in your code, AND
2, you have also encrypted your MDE.
I guess if I had many small clients with many different small
applications, the MDE thing could be a pain. But that is not my
business.
Well, it *is* my business, and it *is* a pain.
The point is:
One shouldn't assume that one's situation is universal and make
blanket statements about what every Access developer should do.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn*********************************@216.196.9 7.142...
The point is:
One shouldn't assume that one's situation is universal and make
blanket statements about what every Access developer should do.
That is why I responded. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Larry L |
last post by:
Access is noted for bloating a database when you add and delete records
frequently. I have always had mine set to compact on close, and that works
great. Now after everyone's advice I split my...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |
