Re: How to error-proof Doug Steel's "FixConnections"?
- From: "Douglas J. Steele" <NOSPAM_djsteele@xxxxxxxxxxxxxxxxx>
- Date: Tue, 1 Jul 2008 09:27:36 -0400
"Hugo Kornelis" <hugo@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:d37k64dnk34nmlnv5ggbvpc5cgj01e2t24@xxxxxxxxxx
On Tue, 1 Jul 2008 07:14:29 -0400, Douglas J. Steele wrote:
What I do to ensure that errors like this don't ever occur is limit what
the
users can select as input to the function. For instance, I'll give them a
choice of between their Development, Acceptance and Production versions,
rather than letting them type in the server and database name. Typically,
I'll do this by having an INI file that includes the valid parameters, but
you could also store the information in a table in the front-end.
Realistically, in a situation like this, it doesn't make sense to let the
users type in the value (nor even to choose from a list of valid servers
and
valid databases on the selected server: the application is only going to
work with specific databases!)
I'd love to do something similar, but I'm afraid I can't. The way it
works is that I send a backup of a SQL Server database and an Access mdf
file to my customer, together with instructions on how to create a new
SQL Server database from the backup, how to get rid of the annoying
warning when opening the Access file by signing it with his own
certificate, and instructions on how to change the connection strings
for the linked table (i.e., how to use that form I made that calls
FixConnections in the background).
You may have missed my point. Someone (even if it isn't you) will know which
database(s) they've created on which server(s). Since it only makes sense to
connect to those databases, store have them store that information
somewhere.
I might be able to exercise some control over the database name they
choose when "restoring" the backup I send them (though I'd rather give
them the ability to choose their own, in case they already have a DB
with that same name). But there is absolutely no way for me to have any
control over the server (and possibly instance) name they have their SQL
Server installed on. (And in case you want to suggest using a dropdown,
that would indeed prevent typos but it would saddle me with the burden
of keeping seperate copies of the .mdb for each customer, and of having
to change the list of values for the dropdown every time a customer
makes a change to their domain topology).
I don't see how having a separate INI file is a burden, or, as suggested,
they can store the information in a table.
As an afterthough, you might want to add the error handling you
suggested to your own copies of the code as well. Though a limited
choice doesn't allow for typos, there's still the possibility of the
code being run by a user with unsifficient authorisation in a database,
or at exactly the moment a DBA decides to set the database to single
user mode for some emergency maintenance. In those cases, you too would
lose a linked table!
(Just holler if you want me to post my code - though I doubt it'll meet
your bar for code quality. Hey, what can I say, I'm just a simpleton SQL
Server developer.. <g>)
Sure. Send it along. (djsteele at canada dot com) May as well help others.
<g>
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)
.
- Follow-Ups:
- Re: How to error-proof Doug Steel's "FixConnections"?
- From: Hugo Kornelis
- Re: How to error-proof Doug Steel's "FixConnections"?
- References:
- How to error-proof Doug Steel's "FixConnections"?
- From: Hugo Kornelis
- Re: How to error-proof Doug Steel's "FixConnections"?
- From: Douglas J. Steele
- Re: How to error-proof Doug Steel's "FixConnections"?
- From: Hugo Kornelis
- How to error-proof Doug Steel's "FixConnections"?
- Prev by Date: Re: Export records into Excel
- Next by Date: Re: Export records into Excel
- Previous by thread: Re: How to error-proof Doug Steel's "FixConnections"?
- Next by thread: Re: How to error-proof Doug Steel's "FixConnections"?
- Index(es):
Relevant Pages
|
