A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Excel » Links and Linking
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

reposting, MS Document locking



 
 
Thread Tools Display Modes
  #1  
Old October 20th, 2003, 10:39 PM
Tim Schiermeyer
external usenet poster
 
Posts: n/a
Default reposting, MS Document locking

I use win2K client, the file is already shared to the correct group, my
problem is when running an access database that uses the information in a
link table the spreadsheet becomes locked. What is the work around?
Tim
"Ftca" wrote in message
...
What OS do you use?
I take it you don't use win2k server or other server OS?
If you use windows 95/8 its a bit tricky because each file change
may not be updated.
I believe you may get around this by enabling SHARE or file sharing.
Hope this puts you on the right path.



"Tim Schiermeyer" wrote in message
...
Reposting, see below. Does anyone know how to prevent a microsoft

document
(.doc, .xls) from locking up if multiple users need to see the same

file?
If
there is not a way to do this please reply as to such.
Thank you
Tim

"Tim Schiermeyer" wrote in message
...
how do I prevent the read only excel file from locking up when

multiple
users a probing the file by use of an access data base.
Thank
Tim









  #2  
Old October 20th, 2003, 11:21 PM
Albert D. Kallal
external usenet poster
 
Posts: n/a
Default reposting, MS Document locking

"Tim Schiermeyer" wrote in message
...
I use win2K client, the file is already shared to the correct group, my
problem is when running an access database that uses the information in a
link table the spreadsheet becomes locked. What is the work around?



You mean you are trying to turn a spreadsheet into a multi-user database?

If you are paying anyone in your company to set this up, then I would get a
immediately refund on time spent. I mean, really, there has to be at least
somewhat of a base level of competency here.

Spreadsheets are not mutli-user database systems. It is a VERY VERY bad idea
to try and turn a spreadsheet into a multi-user database. Your IT people
should at least have some pride in their workmanship here.

You can certainly setup something to import the data from a spreadsheet into
a access table. However, it is sheer nonsense to try and turn a excel
spreadsheet into a database.

You owe yourself, and your company such more then trying to use a
spreadsheet for something it is not designed. I would suggest you consider
brining in a good developer, or at least someone who understands the
difference between a database and a spreadsheet.

You have no control, or any kind of verification of data and how it is
entered into a spreadsheet. It is sheer folly to try and get this to work.

Where I come from, people get fired over doing stuff like this.

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn



  #3  
Old October 21st, 2003, 12:17 AM
Tim Schiermeyer
external usenet poster
 
Posts: n/a
Default reposting, MS Document locking

This table is update by one person, all users are read only, they do not
have write access to the spread sheet. This is only done for the simplicity
of editing the table, i.e. making additions to the table. I did not wish to
construct an entirely separate database. For these entries are pulled from a
client side constructed DB. This is a simple link table utilized within a DB
and I do know the difference, for ease of additions I choose to use the
spreadsheet. Even if I were to make this a import within the client side DB
there could be an issue with pulling the data if multiple users pull the
data at the same time. Currently I have read only permission set for all
users except myself and I think the issue could be tied to when I only the
data-base on different desktops since I have read/write privileges. Do you
still think that this design is wrong???
Tim
"Albert D. Kallal" wrote in message
news:1eZkb.135620$6C4.124759@pd7tw1no...
"Tim Schiermeyer" wrote in message
...
I use win2K client, the file is already shared to the correct group, my
problem is when running an access database that uses the information in

a
link table the spreadsheet becomes locked. What is the work around?



You mean you are trying to turn a spreadsheet into a multi-user database?

If you are paying anyone in your company to set this up, then I would get

a
immediately refund on time spent. I mean, really, there has to be at least
somewhat of a base level of competency here.

Spreadsheets are not mutli-user database systems. It is a VERY VERY bad

idea
to try and turn a spreadsheet into a multi-user database. Your IT people
should at least have some pride in their workmanship here.

You can certainly setup something to import the data from a spreadsheet

into
a access table. However, it is sheer nonsense to try and turn a excel
spreadsheet into a database.

You owe yourself, and your company such more then trying to use a
spreadsheet for something it is not designed. I would suggest you consider
brining in a good developer, or at least someone who understands the
difference between a database and a spreadsheet.

You have no control, or any kind of verification of data and how it is
entered into a spreadsheet. It is sheer folly to try and get this to work.

Where I come from, people get fired over doing stuff like this.

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn





  #4  
Old October 21st, 2003, 01:27 AM
Albert D. Kallal
external usenet poster
 
Posts: n/a
Default reposting, MS Document locking

The problem is that ms-access as a database works with each row of data.
With a spreadsheet, to save one row, the WHOLE SHEET must be written to
disk. ms-access has no ware to "work" with one part of the spreadsheet. It
is kind of a all, or nothing deal.

However, you do make a better case here, as at least you only want ONE
person to be able to edit, but allow multiple people to view the data. So in
fact, you are not trying to allow multiple updates. I am guessing when
ms-access opens the table, it opens it exclusive, regardless of read/write
settings. There is just no mechanism built in to reflect changes to the read
only users.

I would perhaps just send the data out to some web server, or some html
document, and let the users view it that way. Even a pdf doc, or snapshot
report doc might be the way here. Multiple users into a linked spreadsheet
is not much workable. Perhaps you could setup some process to dump the data
from the spreadsheet into a some linked temp table on a timed bases, and let
the users report/view that.

I just don't see ms-access is the right tool to allow multiple users to view
linked excel spreadsheet data. You need to send that data out of Excel into
some kind of viewable source for those users to view.

As for ease of data entry, generally ms-access is far better then excel.
Also, continues forms in ms-access are quite nice and look much like
spreadsheets anyway (except you get things like combo boxes, and even
database lookups to save typing).

Here is some forms screens that look like spreadsheets, but are fact
continues forms in ms-access, and they behave very much like grids:

http://www.attcanada.net/~kallal.msn/Articles/Grid.htm

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada

http://www.attcanada.net/~kallal.msn


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 11:13 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.