Stop Using Sharepoint

  • Thread starter Thread starter Jphillip
  • Start date Start date
J

Jphillip

I have created a database that is working great, however we had to move it to
sharepoint so that multiple offices could use it. Now however we want to make
it so that it is local only, and not on sharepoint. Is there a way to
perminatly disconnect sharepoint from my database.
 
I know of no way to disconnect from SharePoint. You may be able to sync the
data locally, then reconnect it with a copy of the database front-end you
used to publish it in the first place. You may want to ask this in a
SharePoint newsgroup as well.

Just curious: Why do you want to disconnect from SharePoint anyway?
 
Well there are 2 purposes for my questions. While I currently do not want to
disconnect the original database as it is still being worked with, there is a
new program that is being worked on in another state that is exactly the same
as mine and they want to use the same database. That being said, rather than
building a whole new database, it is far easier to disconnect sharepoint from
a local copy of the database and let them start from the bare stucture of the
database.

The second reason is that the database can be very slow on sharepoint, we
have over 1500 records and it is growing. While I need it accessable with
multiple offices, we are looking at other possibilites such as citrix to
speed up this. When we do switch over I need to take away sharepoint for
good. If anything here puts up a red flag for a better way to do this I would
be happy to go more in depth as to how my database is structured. I am kind
of a self taught access user.
 
Hopefully you have the original copy of the database that you can simply
sync with. If not, you will have to create a copy, and sync with that.
 
BTW, I use Access with a terminal server as well. The performance is great
up to about 15 users, then it slowly begins losing performance until about
30, when it too gets slow. The advantage though is that it is not as size
limited when considering speed. Well indexed tables with 10s of thousands of
records return results in under a second.
 
I was just reading that yesterday. What does that exactly mean "indexed".
Once again, I am a self taught user, and while I am fairly computer savey, I
am no professional. Right now all of my tables have a primary key that is
indexed, is that all I am looking for?
 
I was just reading that yesterday. What does that exactly mean "indexed".
Once again, I am a self taught user, and while I am fairly computer savey, I
am no professional. Right now all of my tables have a primary key that is
indexed, is that all I am looking for?
Click to expand...

Not really!

An "Index" is a datastructure within a database which Access uses to make
finding and sorting records faster. A Primary Key is one type of index; if you
use the Relationships window to define a relationship between two tables,
Access creates another Index on the joining field in the "many" side table.

You can also select any field (except for Memo or OLE fields) in a table and
use the field properties window on the lower left of the screen to create an
Index. This can be "unique" (if you want the field to be restricted so that no
value in it ever occurs twice) or not as appropriate.

You can also use the Indexes tool - looks like lightening hitting a datasheet
- to create indexes, either on single fields, or a single index covering
multiple fields.

Indexes make it faster to retrieve records by searching, and make sorting
records on the indexed field faster. They can also enforce uniqueness and are
used in joined-table queries (hence their automatic creation).

The downside is that though they make data retrieval faster, they can make
data updating slower (Access must populate both the table and the index when
you add or edit a record). They also make the database larger, and there is a
limit of 32 indexes on any one table. It can be sort of a black art to
determine which fields should be indexed and when the index should be omitted,
but proper indexing is very important to a well designed database; as a rule
of thumb, fields that you'll routinely use for searching and sorting should be
indexed - e.g. you might want a three-field index on LastName, FirstName and
MiddleName if you'll usually be sorting names in that order; or separate
indexes on LastName and FirstName if you'll often be sorting or searching on
either name.
 
"John W. Vinson" <jvinson@STOP_SPAM.WysardOfInfo.com> a écrit dans le
message de groupe de discussion :
(e-mail address removed)...
 
Back
Top