Re: Turtle like speeds connecting to db across network

Ahhh, kinda assumed you were using SQL-Server/Oracle there Doh!

- You'd be better off converting the Access DB to SQL-Server rather than
using say linked Access tables
- If you have SQL-Server 6.5 you might consider using MSDE 2000, its
SQL-Server 2000 compatible, free, and is intended as a kind of Access/Jet
replacement, although you don't get the enterprise GUIS (Enterprise Manager,
Query Analyser etc). SQLServer 2000 contain alot of enhacments not found in
6.5/7
- I can't think of a reason you can't use 6.5 with .NET
- If you've been using Access for DB solutions, the transition to
SQLServer/MSDE shouldn't be that difficult
- If you're using .NET and SqlServer/Msde, use the SqlServer variant DB
classes instead of the OleDb variants, they're optimised for use with
SqlServer (SqlConnection instead of OleDbConnection etc in the
System.Data.SqlClient Namespace)

Regards,
Phillip Allan-Harding

Graphicboost Ltd.
Tel: +44 (0)161 980 4136
Mobile: +44 (0)7778 561119
Email: [email protected] <mailto:[email protected]>
Web: http://www.graphicboost.com



-----Original Message-----
From: Saye, Robert [mailto:[email protected]]
Sent: Friday, 04 October 2002 15:03
Subject: Re: Turtle like speeds connecting to db across network


Well Christer is correct, I am using an Access 2000 database. All of the
queries and inserts I tried to write in a reusable way. The ones that seem
the slowest are the extremely complex ones. For instance, I have a combo box
filled with supplier's names. After a selection is made, I fill a label with
all the information about the supplier (Address, phone etc) Then I have a
second combobox which I fill with all the contacts associated with the
supplier. All in all after the supplier is selected, I do three queries:
1. Query the db for the supplier's info.
2. Take the state ID from the Supplier's info and run another query to get
the state name.
3. Select all the contact's who are associated with this supplier.
Then I push all the info into a label below the combobox.

On my development computer, this is almost instantaneous. When I moved to
the network, there is a noticeable pause while this takes place( The 1:10
may have been an exaggeration... but not much of one).

So here are a few other questions, we have an SQL Server 6.5 here that I
could probably use some space on. (You may have figured out by now that I
don't normally do this :)) Can I use the existing database as a front end
and the server as the backend? Will this significantly enhance my speeds?
Should I just convert my database to SQL server? Lastly can you even use SQL
Server 6.5 with the .Net framework? As a small company, we don't have a DBA
here. I am actually the only person in the company who has read a single
book on databases. So our IT guy is in charge of it. He really doesn't know
how to use it, so I have to go to him with a solution not a problem.

Again,
  Thank you for your time.
Robert Saye

-----Original Message-----
From: Phil Allan-Harding [mailto:[email protected]]
Sent: Friday, October 04, 2002 8:40 AM
To: [email protected]
Subject: Re: [OLEDB_DEV] Turtle like speeds connecting to db across
network
Importance: High


Thats rather surprising (10x), it depends a lot on:

- The DB schema
- The type & syntax of your DML (selects, inserts etc)
- The data access interface being used by client(s) (ADO, OLEDB, ODBC etc)

How you can optimise a schema is largely dependent on the RDBMS for it's
"optimisation rules"
Design the schema/parts of the schema with it's intended purpose in mind
(OLAP, OLTP)
Don't blindly follow the normalisation rules, doing so can have a
deletorious effect
Bear in mind that the use of SPs, in performance terms, can outstrip DML in
some circumstances
Match the solution to the requirement
Read the RDBMS documentation sections concerning performance thouroughly

X------X SNIP

You can read messages from the OLEDB_DEV archive, unsubscribe from
OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.