SharePoint Services

#11

Albert, Salad and David:

Your comments, thoughts and recommendations are appreciated and well
received.
So in response to clarify my situation, I will point out that :
1. We are 23 users spread over a 'wide area' of the northeastern US
(Buffalo, NY to Boston, MA to New York, NY)
2. We are but a small department in a very large utility corporation with
an IT Department that is extremely diligent in its protocols, protections
and updates.(Actually, they are a pain in the ass)
3. IT does not support our Access app explicitly as the app is considered
part of the company's standard MS Office Pro 2003 running on an XP OS. IT's
only direct involvement w/ our MSAccess app is that we were given a
dedicated directory upon which our app resides along with approx 50 other
files/folders in our dept. Also, because it sits on the network, it gets
backed up nightly.
4. The app is a 'split' mde with only the BE sitting on the network
directory.
5. There is a persistent connection to the BE on startup which is a hidden
little two-record form.
6. In that our company operates on the 'cheap', I suspect there are
bandwidth issues because IT constantly complains about our department's
video-streaming usage and the bandwidth problems that it causes.
7. All of the applicable tips put forth by Tony Toews and Allen Browne were
adopted as well as those in other publications such as Helen Feddema's
Access Application Development and another very useful one entitled 'Access
Annoyances'
8. The network is slow per se in that sometimes our 'Outlook' email program
drags (but how do you tell IT that their network is not configured properly
(especially when I am definitely not an IT professional and would have no
idea how to "fix" their configuration.
9. I do believe that too much data is being trafficked over the network and
am looking to cut that down by such things as having only the user's case
opened by the user's ID instead of opening all records to him.
10. When I use my Demo copy of the app (BE and FE placed on my 'C' drive),
it 'flies'. On the network, the Live version crawls. I point this out
because of the references made to 'bad design' or 'inefficient design'. How
do you tell if it's 'bad design' if it works beautifully as a Demo
(everything on the HD) and crawls when the BE is on the network?
11. I haven't yet gotten IT's approval to move all of the other
folders/files down one level on the directory, so I don't know yet if that
will improve the speed.
12. Albert- that is a great question that I will ask my IT person regarding
the amount of users and network traffic on my current server because I have
no idea. I don't know how many servers are in use or their current usage--I
do know there are 18k employees in the company, half in the 'field' and half
of which are office types w/ computers at each desk. Maybe a dedicated
server will work to speed up the app.
13. Are there any books you'd recommend on how to take advantage of
'limited bandwidth' by better design of the app?
14. My original question was answered and that was SharePoint (and SQL
Server) will not necessarily 'speed up' anything. It's in the design (back
to No. 13 above).

Thanks again for all of your input...

Earl

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote

Quote:

"Earl Anderson" <isobadd (AT) optonline (DOT) net> wrote in message
news:49e6a149$0$5940$607ed4bc (AT) cv (DOT) net...

I didn't read/see anything in this thread about performance. Would
placing the BE on SharePoint improve performance (speed)?

In most experience moving the backend data to sharepoint or even SQL
server will not fix performance problems. MS access is no slower than the
vb.net when using SQL server as the backend database.

All of the advantages of the many features and functions in the Access
app are totally diminished by its 'slowness' on our network. I'm
searching for ways to improve the performance

As I stated moving the backend data to SQL server will usually slow it
down even more. It is only when you modify your design to take advantage
of SQL server who will you see an increase in performance. 9 out of 10
times the issues of performance is due for the follwing reasons:

1) something in the network is not set up correctly or the network is
simply slow.

2) something in the configuration setup of MS access is not correct and
that's making things slow

3) the design of the architecture the application is dragging too much
information over the network.

such as having IT move all of the other folders/files one level down from
our app so that it stands alone on the directory it's located.

Did the above move help at all? If the above made no difference, then the
above was not a issue for you. In other words this deeper directory issue
does not always affect performance on some networks. So, this issue made
have done nothing to help you, but at least it good to resolve one issue
out of a long list of issues.

Yes, all of the updates, solid connections, patches, etc. are preformed
by IT nightly thru their Radaii system. All of our queried fields are
indexed. The auto name correct (or whatever it is called) is turned off
as well as in the subforms.

The first number one issue on this list of network things to check is to
enusre ensure that you have a persistent connection. I think this advice
is given here once every other day in these newsgroups. for some of my
clients this does not make a difference, for others it increases
performance by five times or more. so I assumed that you create an mde,
and this front and NT is a place on each computer. I assume that in your
startup code you open a connection to the database (back end) and keep
this connection open at all times.

I'm trying to convince IT to give (purchase) us our own server so that
nothing else is on it but our app as this may speed queries, opening
forms, and printing significantly..

I doubing the above would help unless there is a significant amount a
users and network traffic and workload on that server you have now.

Thus I was intrigued by this discussion here on the SharePoint
possibility as our department has recently been introduced and given an
IT -sponsored/supported SharePoint portal. Maybe this is the answer.

An insights and thoughts here are appreciated....

There's no question that you can get a SQL server backend database, or
tables linked to share point to run in a lesser bandwidth environment.
However in many cases the advantages of this technology can only be had if
you're architecture (desing of your application) takes advantage of a
limited bandwidth.

I going to repeat this again:
Moving your back end database to a super duper high speed corporate
cluster of 10 SQL servers capable handling a thousand uses at once without
breaking into a sweat will NOT improve the performance of the application
if you've not designed it well as such a to reduce bandwidth requirements.
You can increase the performance that server as much as you want, the
problem is you're not changing your network nor are you changing the
bandwidth of your network. in most cases to take advantage of these new
technologies you have to have designs that are such that respect the
network you are on.

So, is SQL server or share point a possibility for you? Yes. will move
into share 0.0 SQL server solve your performance problems of magically
without effort on your part? NO.

You don't mention how many users and what is the max size of tables in
your application. Maybe it's possible that you've simply grown your
current network infrastructure and therefore you're suffering performance
problems. In other words let's say your application runs well if two
users, but when you run twenty users it runs too slow.

So after how many users does your application start slow down? At what
point are you finding your network and your application running too slow?

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

#12

Earl Anderson wrote:

Quote:

10. When I use my Demo copy of the app (BE and FE placed on my 'C' drive),
it 'flies'. On the network, the Live version crawls. I point this out
because of the references made to 'bad design' or 'inefficient design'. How
do you tell if it's 'bad design' if it works beautifully as a Demo
(everything on the HD) and crawls when the BE is on the network?

I had a similar problem but with A2003. My BE filename was something
like ThisIsALongMDBname.MDB. It might have been in a folder path like
F:\FolderName1\FolderName2.

I can't remember what REALLY turned it right but I know changing the BE
name to something like AppBE.MDB really speeded it up. It now fit the
DOS 8.3 format. I'll assume your BE is off the root folder like
F:\AppDir. Since I got burned once, I keep my folder and filenames short.

Oh...one other thing that brought the system to its knees...they were
using Norton Enterprise and it was set up to scan Office files. Once we
turned off the scanning of the MDB things improved dramatically as well.

#13

Yeah, I get a little smirk on my face every time that I type in the "POS"
command which they use as a shortcut to the invoicing (Point Of Sale)
component.

Both of these text-based apps (AutoPoint and Rinax) have obviously had many
"band-aids" applied to them over the course of their lifetimes. It's really
an inconsistent and confusing environment ... which truly frustrates me
based on what (admittedly limited) knowledge I have picked up on database
design.

One quick example:
There is an archaic means to search for a customer name while creating an
invoice.
"DON" [Enter] would display my name ... seeing as how someone entered it in
the "FirstName LastName" format. <groan>
"LEV" would not find it.
"LEV" + [Shift - F5] would find it, however... "RTFS" (Read The F-ing
Screen) as the tech support guys say ...
Selecting it (using up and down arrows), and then hitting [Enter] pops the
account # into the correct field.
That's all well and good if you were creating a new invoice, but there is no
warning that there is already a suspended invoice.

The only way (well the quickest way) to determine if a suspended invoice
already exists is to manually type in the account number and then hit [F7]
.... BEFORE hitting the [Enter] key. One the enter key has been pressed,
you've created a new record (invoice).
So, OK ... I'll just get in the habit of doing the F7 thing first then,
right? Oh no ... if there are no suspended invoices ... you are "booted"
right out to the point that you have to re-enter the invoicing app and
re-enter the customer number.

*muttering "POS alright"*

This thing is Linux-based as well, which often results in some very strange
keyboard behavior. Hitting the [Backspace] key results in "[~", and the
[Esc] key usually results in getting somewhere that you really don't want to
be ... like at the "Change Branch" prompt. It amounts to "unlearning" most
of the things that have become second nature. Kinda tempts me to try the old
"3-finger salute" key combination ... just for giggles.

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote

Quote:

"Don Leverton" <NoDamnSpam (AT) Telus (DOT) Net> wrote in
news:W9yFl.23696$PH1.16940@edtnps82:

I've managed to export a customer list from the Amador AutoPoint
Software ... which was in turn imported from another POS (dual
meaning there) text-based software program from Rinax.

This made me laugh out loud for a very long time.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

#14

"Earl Anderson" <isobadd (AT) optonline (DOT) net> wrote

Quote:

So in response to clarify my situation, I will point out that :
1. We are 23 users spread over a 'wide area' of the northeastern US
(Buffalo, NY to Boston, MA to New York, NY)

Ok...you using a wan. I am VERY surprised you can get ANY decent performance
working on a system as above. Read my following article on access + wide
area networks:

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

Quote:

6. In that our company operates on the 'cheap', I suspect there are
bandwidth issues because IT constantly complains about our department's
video-streaming usage and the bandwidth problems that it causes.

As mentioned, read my above article. Your wide area network is likely 10 to
100 times slower then your typical office lan. However, the fact that you
have this working on a WAN tells me you have a 1st class and 1st rate
system. You should NOT be having the success you are now in the first place
on a wan.

Quote:

8. The network is slow

See my article. The question you need to ask is how much slower is this wan
then a typical office 100 base network. I don't need a bits/bytes/baud rate.
Simple how fast compared to a standard cheap-o office LAN (100 base).

I mean, if the network is 100 times slower, or even 10 times slower, then
improving your performance by 30% is likely a waste of time here. With this
type of network, it close to a given that you need sql server here.

Quote:

it 'flies'. On the network, the Live version crawls. I point this out
because of the references made to 'bad design' or 'inefficient design'.
How do you tell if it's 'bad design' if it works beautifully as a Demo
(everything on the HD) and crawls when the BE is on the network?

Well, how well does it run on a typical office network, not that very slow
WAN?

When you run the application local off the hard drive, it quite hard to
ascertain any performance bottle necks because you using a local hard drive
without a network...it going to be fast even with poor designs...

Quote:

12. Albert- that is a great question that I will ask my IT person
regarding the amount of users and network traffic on my current server
because I have no idea.

Actually, my question was for your application. In other words it is ok
after 3 users, but with 15 it is too slow. I was not really asking about
"other" applications. You telling me this runs slow with 1 user. so, that a
very important point here. I tells me that it not the number of users that
causing a slow down..but it always slow...slow with 1 user.

Quote:

I don't know how many servers are in use or their current usage--I do know
there are 18k employees in the company, half in the 'field' and half of
which are office types w/ computers at each desk. Maybe a dedicated server
will work to speed up the app.

Not likely at all. As I said, this likely is not processing issue or speed
of your server. It is an issue of bandwidth. You can't even normally get
access to run well on a WAN. In fact, since you been able to do this...it
actually speaks well for your application design..

Quote:

14. My original question was answered and that was SharePoint (and SQL
Server) will not necessarily 'speed up' anything. It's in the design
(back to No. 13 above).

Well, given your limited bandwidth. then Sql server is most certainly a
option here. You have to tweak your front end. If you don't want to use sql
server, then terminal services is your ticket.

So, If you do not want to re-write anything at all, then as per my WAN
article...terminal services is a good option here. You also don't have to
install access (or your application) on any of the target machines..so,
distribution and maintains is also very easy this way.

I surprised you not suffering data corruptions on your wan now. It sounds
likely you have a VERY top of the line WAN, since after reading my
article...you will find that your setup is usually not workable at all..and
you seem to be able to get this to work....

The big detail left out here is that your using a WAN....and not a typical
office LAN....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com

#15

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote:

Quote:

I don't think your record count issues are too big of a problem
for SharePoint.

I'd be wary of giving up referential integrity for an app like this.
A mailing list is not so important (Sharepoint uses "list" to refer
to its "data tables" for a reason, I think), but something like an
ordering and inventory system really needs proper data integrity
enforcement in the database engine.

I agree with those concerns.

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/

#16

"Don Leverton" <NoDamnSpam (AT) Telus (DOT) Net> wrote:

Quote:

Our company has 3 branches, and we already use some sort of "VPN" to tie us
all together.

Enter the SharePoint idea.

I've read through the thread of postings so far.

I'd strongly suggest the SQL Server approach instead. As mentioned by others
SharePoint doesn't do referential integrity and I expect it's going to have more
quirks than SQL Server would.

You can likely setup SQL Server Express on a "server" system in your home store, even
if it's just a regular computer. For your volume of data you won't need anything
fancy. Heck a three or five year old 1 GHz system would likely be just fine. Note
that we'd prefer a stand alone computer as otherwise a user might decide to reboot it
if starts acting wonky when they are running another program or whatever.

I'm a bit hazy on the VPN details which you already have in place. But using such a
VPN for your other two stores to contact the SQL Server database at your store is an
excellent idea.

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/

#17

"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote:

Quote:

I'd strongly suggest the SQL Server approach instead. As
mentioned by others SharePoint doesn't do referential integrity
and I expect it's going to have more quirks than SQL Server would.

Also, it seems to me that Access developers (at least the ones who
post in the Microsoft public forums) aren't really flocking to
Sharepoint. There's a much deeper store of knowledge and tips for
using SQL Server than there is for Sharepoint.

I think the biggest reasons is the lack of referential integrity. That just plain
bothers me. <smile>

That said SharePoint is being sold lots by Microsoft. And there's usages for it. I
can see one client of mine pushing some data to SharePoint to make lists of data
available to construction site personnel such as foreman.

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/

#18

"Don Leverton" <NoDamnSpam (AT) Telus (DOT) Net> wrote:

Quote:

Enter the SharePoint idea.

On thinking about my previous point suggesting SQL Server only was premature.
Solutions such as Terminal Server or Thinsoft which we also recommend in a WAN
environment would also work quite well in your situation. And would not require you
to learn how to use SQL Server.

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/

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SharePoint Services

comp.databases.ms-access comp.databases.ms-access

Re: SharePoint Services - 04-16-2009 , 10:43 PM

Re: SharePoint Services - 04-16-2009 , 11:20 PM

Re: SharePoint Services - 04-17-2009 , 12:56 AM

Re: SharePoint Services - 04-17-2009 , 12:14 PM

Re: SharePoint Services - 04-17-2009 , 06:57 PM

Re: SharePoint Services - 04-17-2009 , 07:26 PM

Re: SharePoint Services - 04-18-2009 , 02:32 PM

Re: SharePoint Services - 04-18-2009 , 02:35 PM