Locking

The application is used by one and only one person at head office.

It is used by one and only one person at each of about seventy sites. Site
data are discrete; there is nothing (that can be edited) that Site 1
shares with Site 2.

In short no user shares or has access to the data any other user may use.
In addition, all or almost all data entry is a one-time thing. Updates will
be about as rare as a school having its name changed.

For this part of the application I am using html forms. It will be cheaper
and easier to ignore the whole notion of locking.

Locking seems to be unnecessary, and this application will never be used in
another way by another group of users.

But there is something within me that says, "But you can't deliver such an
application (without any provision for record-locking), even if that lack
can't cause a problem and even if you document it and even if you explain
to and get approval from the client. A good application must provide for
record-locking so that one user does not unknowingly overwrite another
user's edit!"

What do you think?

--
lyle fairfield

I will arise and go now,
For always night and day
I hear lake water lapping
With low sounds by the shore;
While I stand on the roadway
Or on the pavements gray,
I hear it in the deep heart's core.
- Yeats

Re: Locking

On Nov 20, 6:18 am, lyle fairfield wrote:
> The application is used by one and only one person at head office.
>
> It is used by one and only one person at each of about seventy sites. Site
> data are discrete; there is nothing (that can be edited) that Site 1
> shares with Site 2.
>
> In short no user shares or has access to the data any other user may use.
> In addition, all or almost all data entry is a one-time thing. Updates will
> be about as rare as a school having its name changed.
>
> For this part of the application I am using html forms. It will be cheaper
> and easier to ignore the whole notion of locking.
>
> Locking seems to be unnecessary, and this application will never be used in
> another way by another group of users.
>
> But there is something within me that says, "But you can't deliver such an
> application (without any provision for record-locking), even if that lack
> can't cause a problem and even if you document it and even if you explain
> to and get approval from the client. A good application must provide for
> record-locking so that one user does not unknowingly overwrite another
> user's edit!"
>
> What do you think?
>
> --
> lyle fairfield
>
> I will arise and go now,
> For always night and day
> I hear lake water lapping
> With low sounds by the shore;
> While I stand on the roadway
> Or on the pavements gray,
> I hear it in the deep heart's core.
> - Yeats

Whether it is a requirement or not from the client, you give 'em the
pros and cons. If they want it - give it to them! Giving the
application exclusive locking will give it a performance enhancement.

Re: Locking

On Nov 20, 9:18 am, lyle fairfield wrote:
> The application is used by one and only one person at head office.
>
> It is used by one and only one person at each of about seventy sites. Site
> data are discrete; there is nothing (that can be edited) that Site 1
> shares with Site 2.
>
> In short no user shares or has access to the data any other user may use.
> In addition, all or almost all data entry is a one-time thing. Updates will
> be about as rare as a school having its name changed.
>
> For this part of the application I am using html forms. It will be cheaper
> and easier to ignore the whole notion of locking.
>
> Locking seems to be unnecessary, and this application will never be used in
> another way by another group of users.
>
> But there is something within me that says, "But you can't deliver such an
> application (without any provision for record-locking), even if that lack
> can't cause a problem and even if you document it and even if you explain
> to and get approval from the client. A good application must provide for
> record-locking so that one user does not unknowingly overwrite another
> user's edit!"
>
> What do you think?
>
> --
> lyle fairfield
>
> I will arise and go now,
> For always night and day
> I hear lake water lapping
> With low sounds by the shore;
> While I stand on the roadway
> Or on the pavements gray,
> I hear it in the deep heart's core.
> - Yeats

I think it's a great poem. My grandfather once told me that fishing
is not about catching fish. You've never been one to prefer the
concrete of dogma to the fluidity of reason. Yet I think about what I
would do in similar circumstances and realize that I wouldn't slough
off those concerns without at least considering their possible
effects, both now and in the future.

James A. Fortune
CDMAPoster@FortuneJames.com

The various kinds of human institutions have developed the inertia
they
have over time. There's an underlying reason why they have a given
resistance to change. -- Dr. Gilbert Wedekind

Re: Locking

lyle fairfield wrote:
> The application is used by one and only one person at head office.
>
> It is used by one and only one person at each of about seventy sites. Site
> data are discrete; there is nothing (that can be edited) that Site 1
> shares with Site 2.
>
> In short no user shares or has access to the data any other user may use.
> In addition, all or almost all data entry is a one-time thing. Updates will
> be about as rare as a school having its name changed.
>
> For this part of the application I am using html forms. It will be cheaper
> and easier to ignore the whole notion of locking.
>
> Locking seems to be unnecessary, and this application will never be used in
> another way by another group of users.
>
> But there is something within me that says, "But you can't deliver such an
> application (without any provision for record-locking), even if that lack
> can't cause a problem and even if you document it and even if you explain
> to and get approval from the client. A good application must provide for
> record-locking so that one user does not unknowingly overwrite another
> user's edit!"
>
> What do you think?

I think you have to make some assumptions so that you can sleep at
night. You have already made the assumption that the data will not be
used in any way other than by your web application. Add a time stamp
field to the tables that are possible to edit using your application
and assume that checking it before writing back handles the problem.

Of course, then you will have to add a collision resolution interface
that will probably never be used.

Re: Locking

On Nov 21, 7:59 pm, rkc wrote:
> lyle fairfield wrote:
> > The application is used by one and only one person at head office.
>
> > It is used by one and only one person at each of about seventy sites. Site
> > data are discrete; there is nothing (that can be edited) that Site 1
> > shares with Site 2.
>
> > In short no user shares or has access to the data any other user may use.
> > In addition, all or almost all data entry is a one-time thing. Updates will
> > be about as rare as a school having its name changed.
>
> > For this part of the application I am using html forms. It will be cheaper
> > and easier to ignore the whole notion of locking.
>
> > Locking seems to be unnecessary, and this application will never be used in
> > another way by another group of users.
>
> > But there is something within me that says, "But you can't deliver such an
> > application (without any provision for record-locking), even if that lack
> > can't cause a problem and even if you document it and even if you explain
> > to and get approval from the client. A good application must provide for
> > record-locking so that one user does not unknowingly overwrite another
> > user's edit!"
>
> > What do you think?
>
> I think you have to make some assumptions so that you can sleep at
> night. You have already made the assumption that the data will not be
> used in any way other than by your web application. Add a time stamp
> field to the tables that are possible to edit using your application
> and assume that checking it before writing back handles the problem.
>
> Of course, then you will have to add a collision resolution interface
> that will probably never be used.

Thanks to all who responded. I'm toying with going back to using an
ADP. But the seventy sites have seventy different combinations of
Windows, Windows Service Packs and Upgrades, Access Versions and
Access Service Packs, and MDAC versions installed. Worse, SQL logons
and permissions for some of these sites are so obscure and convoluted
that the SA cannot say what they are, or how to use them. An ADP,
without individual modification, is likely to run flawlessly on fewer
than half. I do not want to maintain thirty-five or forty versions of
an application, however minor their differences may be. Fix the SQL
Server and the db technology installations? That would require major
political intervention. It ain't gonna happen.
While DAPs are scorned here in CDMA, they do have, TTBOMK, the
advantage of persistent connections, thus handling locking implicitly.
And there is dot NET. Am I skilled enough to create a dot NET
application? Probably not. And how would the sevently sites be at
installing and maintaining a NET framework?
I think I can establish and maintain locking in ASP by creating and
maintaining my recordsets as Session variables. In this way, even
after the html page is rendered, the recordset and connection will
stick around, and the locking should be effective. But when to abandon
the Session variable recordset? What to do when the Session times out?
And what is the over head for the site server if thirty users each
have five recordsets and a connection open concurrently?
....