|
|
Are there any gotchas with making a front end read only by the simple means
of setting the Read Only attribute on the .mdb file?
Not thinking of any security measures here, it would just seem an easy way
of avoiding FE bloat and easily checking what version of it one has and not
having it constantly picked up by file synchronizers, incremental backups,
etc ('cos the modified date on the file wouldn't change every time the FE was
used).
In a similar vein, in a scenario where there are two back end .mdb's, one
that contains frequently changing tables and another with rarely changed (and
centrally controlled) "constants", would there be any gotchas on setting the
Read Only attribute on the constants.mdb file, as well as the FE?
Thanks
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote:
[Quoted Text] >Are there any gotchas with making a front end read only by the simple means
>of setting the Read Only attribute on the .mdb file?
>
>Not thinking of any security measures here, it would just seem an easy way
>of avoiding FE bloat and easily checking what version of it one has and not
>having it constantly picked up by file synchronizers, incremental backups,
>etc ('cos the modified date on the file wouldn't change every time the FE was
>used).
There have been a few people mentioning they tried such without any
adverse reactions. But I don't recall if this stood the test of time.
Now as far as the modified date well who cares. Each user should be
getting their own copy of the FE preferably on thier own system.
Also why would the version matter?
>In a similar vein, in a scenario where there are two back end .mdb's, one
>that contains frequently changing tables and another with rarely changed (and
>centrally controlled) "constants", would there be any gotchas on setting the
>Read Only attribute on the constants.mdb file, as well as the FE?
That would also work I think. However what about relational
integrity?
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
|
[Quoted Text] > Now as far as the modified date well who cares.
Incremental backups and any other utility that might go saving/copying/etc
the file (unneccesarily), thinking it's changed.
>Each user should be getting their own copy of the FE preferably on thier own system.
They do. Although it's not clear why they would need to if the file is
read-only. If having a read-only FE works ok (as it seems to, time will
indeed tell) then it might well allow the use of a single network-based FE
without all the associated corruptions people have reported here. But that's
not our situation, so I'll leave it to someone else to play with that.
> Also why would the version matter?
A surprising question from the author of the Auto FE Updater!
> >In a similar vein, in a scenario where there are two back end .mdb's, one
> >that contains frequently changing tables and another with rarely changed (and
> >centrally controlled) "constants", would there be any gotchas on setting the
> >Read Only attribute on the constants.mdb file, as well as the FE?
>
> That would also work I think. However what about relational
> integrity?
? Why would setting the Read Only attribute affect relational integrity?
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote:
[Quoted Text] >> Now as far as the modified date well who cares.
>
>Incremental backups and any other utility that might go saving/copying/etc
>the file (unneccesarily), thinking it's changed.
Sure but at 20 users times 10 Mb for 200 mb that shouldn't be a
strain. Besides the FE MDB/MDE should be on their local hard drive
and all their data should be on the server.
>>Each user should be getting their own copy of the FE preferably on thier own system.
>
>They do. Although it's not clear why they would need to if the file is
>read-only. If having a read-only FE works ok (as it seems to, time will
>indeed tell) then it might well allow the use of a single network-based FE
>without all the associated corruptions people have reported here. But that's
>not our situation, so I'll leave it to someone else to play with that.
One problem with a shared FE though is your ability to roll out an
update. You have to wait until everyone has exited the MDB.
>> Also why would the version matter?
>
>A surprising question from the author of the Auto FE Updater!
<smile> I deserved that. But let me explain further. You should
have the original FE MDB on the server somewhere anyhow. So you don't
need to worry about backing up the distributed FEs.
>> >In a similar vein, in a scenario where there are two back end .mdb's, one
>> >that contains frequently changing tables and another with rarely changed (and
>> >centrally controlled) "constants", would there be any gotchas on setting the
>> >Read Only attribute on the constants.mdb file, as well as the FE?
>>
>> That would also work I think. However what about relational
>> integrity?
>
>? Why would setting the Read Only attribute affect relational integrity?
There is no relational integrity between the two databases.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
Got a (hopefully small) gotcha. The following now barfs when the FE is
read-only:
sql = "SELECT [Linked Table].* FROM [Linked Table] WHERE etc..."
Set rs = New ADODB.Recordset
rs.Open sql, CurrentProject.Connection, adOpenDynamic, adLockOptimistic,
adCmdText
With rs
.AddNew
!field = etc...
End With
rs.Update
etc
Undoubtedly 'cos CurrentProject.Connection refers to the read-only FE. So,
how do I change this code so it'll update the BE directly?
Thanks
Marios
|
|
Marios <Marios[ at ]discussions.microsoft.com> wrote:
[Quoted Text] >Got a (hopefully small) gotcha. The following now barfs when the FE is
>read-only:
>
> sql = "SELECT [Linked Table].* FROM [Linked Table] WHERE etc..."
> Set rs = New ADODB.Recordset
> rs.Open sql, CurrentProject.Connection, adOpenDynamic, adLockOptimistic,
>adCmdText
>
> With rs
> .AddNew
> !field = etc...
> End With
> rs.Update
> etc
>
>Undoubtedly 'cos CurrentProject.Connection refers to the read-only FE. So,
>how do I change this code so it'll update the BE directly?
You may have this problem in lots of places. I do a *lot* of updates
using this kind of code within VBA. But of course YMMV.
You can figure out the location and name of the BE MDB by reading the
connect string from the table and parsing out the location and name.
Then you can use the SQL IN clause.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
|
[Quoted Text] > You can figure out the location and name of the BE MDB by reading the
> connect string from the table and parsing out the location and name.
> Then you can use the SQL IN clause.
Nice and simple idea, but still gets "Current Recordset does not support
updating".
I think I've got to open a new connection specifically to the BE, but after
looking around a lot I can't seem to find what the right code to do that
is....
|
|
Ok, well found an easy solution. Rather than adding/modifiying records in
the linked tables through the recordset with rs.AddNew, .Update etc, I simply
put together an INSERT or UPDATE query and CurrentDB.Execute it.
Probably not a solution for everyone, but in my case performance isn't an
issue as the number of records and amount of data is small, and there were
only a few places where it did it anyway, so not much in the way of code
changes.
Cheers
Marios
|
|
"Tom Wussernark [MSFT]" <tw[ at ]microsoft.com> wrote:
[Quoted Text] >I would reccomend using Access DAta Projects-- they allow you to have a TINY
>frontend and it's 100 times better, more reliable and faster than this other
>obsolete Access format
Note that this person is really A a r o n K e m p f and that he is not an employee
of Microsoft.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
|