Security, Storing Settings (.txt or .ini files) and Reports....toge ther at last

[Regnab]

I'm creating a database that will be used independently at different
sites (in the same company). Given the fact that there will be
inevitable changes down the track, I'm trying to work out the best way
of setting it up for ease of updates.

This is completely beyond anything I've tried before so if people have
better suggestions on how to do things, feel free. What I am currently
considering is splitting the database, with a password protected back
end and user login on the front end (I used the wizard for login - I
know it isn't bulletproof, but is there any obvious holes I need to
address?). Regardless of location, these files would sit in the same
place (eg C:\BirdDB\). When I needed to update, I would send out the
new front-end which the user could then replace the old FE with. And if
I need to update the BE....well, suggestions please :).

Anyway, the question I had is regarding system settings for each
database such as backup options, defualt settings etc. What is
considered best practice - to store them in another table, in a txt
file or in .ini file. I imagine storing in a table would be limiting as
far as updating those settings. I've done a bit of importing/exporting
txt files in the past, and have never worked with .ini files. I'd like
to know if one would be better/more reliable than the other.

And if I could squeeze in a quick final question... how do people
handle updating/adding reports? I can see that once I roll it out, I
might need to do major updates occasionally, but new reports would be
needed much more often. Is there any way they can be sent as a file?
I've worked with databases where the distributer use to email new
reports and you could add them to a folder, but whether access has the
capability (and if so, whether my coding skills are up to it) is
another question :).

Thankyou kindly,

Reg

[Regnab]

As I go through the Access Group, I notice a number of people seem to
think it's fine to use a table. This would be easiest for me - I just
thought it wasn't good practise. Just seemed a little messy to have a
table with a single record for all the settings. And to clarify, the
database will sit locally on one machine at each site, with multiple
users on the one machine.

Cheers

Reg

[Rick Brandt]

"Regnab" <p.*******@gmai l.comwrote in message
news:11******** *************@n 67g2000cwd.goog legroups.com...

As I go through the Access Group, I notice a number of people seem to
think it's fine to use a table. This would be easiest for me - I just
thought it wasn't good practise. Just seemed a little messy to have a
table with a single record for all the settings. And to clarify, the
database will sit locally on one machine at each site, with multiple
users on the one machine.

Well instead of a wide table with a single row and lots of fields you could use
a narrow table with lots of rows and only a few fields like...

SettingName, SettingValue

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com