Connecting to SQL (1 Viewer)

aspfun

Registered User.
Local time
Today, 04:31
Joined
Apr 22, 2006
Messages
29
My Access app is using ODBC to connect to SQL server.
Network guy want me do not use ODBC. He said that ODBC will cause network traffic.
Is it true? Is there another way to connect to SQL server other than ODBC?
(like ado.net in visual studio)
 

Rx_

Nothing In Moderation
Local time
Today, 02:31
Joined
Oct 22, 2009
Messages
2,803
If the database is a split DB (a front-end application - linked to a back end data store on the network) it will cause network traffic.
One would expect a Network to have traffic.

ODBC won't cause more than other methods including ado.net. I don't like ODBC because it can require going to each PC to set up ODBC. How about a DSN-Less connection instead?

What he might be talking about is setting up a parameter query on SQL Server. If you just have linked tables - a query can pull all the data over the network to the client to sort things out, just to get a record or two. If you build a View on SQL Server or create a PassThroughQuery on Access - the question goes to SQL, sorts things out and returns the answer.

It is not really the connection tool, it is how the connection is used.

Here is an example of using a script rather than the ODBC dialogue box to link to SQL Server. My preference is the SQL Native Client.
http://www.access-programmers.co.uk/forums/showthread.php?t=224121&highlight=dsnless
Download SQL Server Native Client 10.0 (have not tested Client 11.0 for Access 2012)
http://www.microsoft.com/download/en....aspx?id=16978

For Access 2010 SQL 2008 R2 Used SQL Server Migration Assistant for Access to migrate Access Linked Tables up to SQL Server (keep names same)
This is a free tool from Microsoft.
To save time - design new tables/fields in the local Access developemnt copy. Test it out. Then use this tool to move the Access table to SQL Server.

For an ADO Passthrough Query - the following link might be useful to get started:
http://www.access-programmers.co.uk/forums/showthread.php?t=227483&highlight=passthrough
 

mdlueck

Sr. Application Developer
Local time
Today, 04:31
Joined
Jun 23, 2011
Messages
2,631
Network guy want me do not use ODBC. He said that ODBC will cause network traffic.

:eek: "Gasp!!! Someone might want to actually use the precious server!!! It would result in 'network traffic'!!! Gasp!!!" :eek:

Perhaps they are worried about use of non-PassThrough queries which download ALL records from the SQL BE DB and rely on the Access FE DB to sift through the raw data in search of query results.

Following is a post where I describe how I use Access in a Client/Server environment:

Client/Server Architecture
http://www.access-programmers.co.uk/forums/showpost.php?p=1110794&postcount=5
 

Rx_

Nothing In Moderation
Local time
Today, 02:31
Joined
Oct 22, 2009
Messages
2,803
LOL - my thoughs about the network concern, exactly.
I am lucky, our offices throughout the country do have really bad networking.
By going to Citrix, one VM server is sitting in the same box as the VM SQL Server.
So, all the network traffic is very self contained.
When I am in a hurry to get something out, I might just drag it all over.
In some cases, it is hard to justify enhancing every situation with a pass-throughs.
That said, the creation of SQL Server Views to process the data does increase the efficiency - in some cases.

This is worth reading - and using the SQL Profiller (SS Profiler) is sometimes worth the effort.
http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/56c36d96-8cd9-4da4-9cfc-64231ffaec94/

Since Access 2007, the Where clause adds huge efficiencies (well, it depends) when connecting to SQL Server. Even for two tables (if they have a relationship).
They also discuss using a query with a Where clause then "topping off" with MS Access using the unique IIF, Nz... ect. There are some very, very gorry details in this article. I will sum up with some quotes at the end:

You really don't need to use parameters, and it's just going to result in a bunch of expensive coding and programming time that yields you in 99 percent of the case nothing at all. You don't need to use ado, you don't need to use ADO + parameters, and you do not need to use a PTQ either. In fact you can use bound forms and use the access standard built in where clause.

You can use a bound form and bind it to a table of a million records, you can then execute an open form command with a where clause to a particular ID. You will find that only the one record comes down the network. This is true if you using an linked table to oracle, a linked table to SQL server, a linked table to mySql. In fact only the one record will come down even when you're not using ANY SERVER of any type but using a standard back end mdb file share and an index can be used.
- this is most likely referencing Access 2007 and beyond.
My experience in Access 2003 (not on Citrix) indicated SQL Views worked faster wth a single parameter.
So this idea that all records are pulled down when you use where clauses and build parameters on the fly is one of those things steeped in great mythology born of those who read about propaganda about Access. This is much like one of those urban legends where the little boy flushes his pet alligator down the toilet. It then begins to live a life in the sewer system, grows to become huge proportions, and then begins to attack maintenance workers in the sewer system. So just like the urban legend of alligators and the sewer system, it is an urban legend that access will pull down all records when you use linked tables and bound forms. This where clause issue is also the same and works equally well for reports .

In the case of a linked view, then you can in code go:

dim strSql as string

strSql = "select * from view_custOweing where custid = 123"
set rst = currentdb.OpenRecordset(strSql)

And for reports, again the view + openreport works well. In fact, it means you do not have to modify and rewrite existing code, and that much why I suggested views.

Once again SQL server does a very good job of taking the SQL that Access generated on that view plus a couple parameters tossed up by access in a where clause. That sql gets set to the server, and only the one record (or required records) will only come down the pipe.
 

Rx_

Nothing In Moderation
Local time
Today, 02:31
Joined
Oct 22, 2009
Messages
2,803
As far as ODBC vs SQL Server Native Client, I feel it offers great advantages related to this discussion.
SQL Server Native Client (SQL Server Native Client) is a single dynamic-link library (DLL) containing both the SQL OLE DB provider and SQL ODBC driver. It contains run-time support for applications using native-code APIs (ODBC, OLE DB and ADO) to connect to Microsoft SQL Server 2005, 2008, 2008 R2, and SQL Server 2012. SQL Server Native Client should be used rather than Microsoft Data Access Components (MDAC) to create new applications or enhance existing applications that need to take advantage of SQL Server features such as Multiple Active Result Sets (MARS), Query Notifications, User-Defined Types (UDT), and XML data type support. This redistributable installer for SQL Server Native Client installs the client components needed during run time to take advantage of new SQL Server code name ‘Denali’ features, and optionally installs the header files needed to develop an application that uses the SQL Server Native Client API.

Latest download: http://microsoft-sql-server-native-client.updatestar.com/

And, for the purpose of overwhelming the Network guy... (LOL)
http://msdn.microsoft.com/en-us/sqlserver/ff658532.aspx
Show him it is compliant with all of the network guy's suggestions. It will reduce network traffic. Mainly, if the connection string is programmed, it reduces the need to go to each client workstation and set up ODBC. That alone will probably make the network employee happy?

Thanks mdlueck for some very impressive code links!
At some point, it would be great to test our methods and publish them with SS Profiler analysis. There doesn't seem to be enough good material about this for Access users.
 

mdlueck

Sr. Application Developer
Local time
Today, 04:31
Joined
Jun 23, 2011
Messages
2,631
At some point, it would be great to test our methods and publish them with SS Profiler analysis. There doesn't seem to be enough good material about this for Access users.

The ODBC SQL Server driver which ships with Windows XP / Windows 7 verses the SQL Server Native Driver, or some other comparison?

For my application I must use the one that ships with Windows so as to not require any additional software to support my application, so I do not foresee testing the Native Client at this client.
 

Rx_

Nothing In Moderation
Local time
Today, 02:31
Joined
Oct 22, 2009
Messages
2,803
Thanks for that reminder about the constraint.
Each of us have those kind of things as a part of our business. It just goes with the territory. And you are right, the guy asking the question could have the same constraint.

I am very lucky to be able to go into SQL Server as an administrator.
Have been in other locations where just requesting a View on SQL was almost as difficult as donating a kidney.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:31
Joined
Aug 30, 2003
Messages
36,128
Perhaps they are worried about use of non-PassThrough queries which download ALL records from the SQL BE DB and rely on the Access FE DB to sift through the raw data in search of query results.

This is not accurate. JET/ACE is pretty good at sending the SQL back to the server to process if it can. If the query can't be understood by the server, then what you describe will happen. An example:

SELECT Format([Enter_date],"dd/mm/yy") AS Expr1
FROM TableName
WHERE Format([Enter_date],"dd/mm/yy")="05/01/13"

returns 700 records from a table with 2.3 million in about 38 seconds. This

SELECT Enter_date
FROM TableName
WHERE Enter_date=#1/5/2013#

returns the same records instantaneously. SQL Server doesn't understand the Format() function, so has to send all the records down, as you described. Since it understands the second (or more accurately JET/ACE can translate for it), it only sends down the 700.

Leigh describes this pretty well here in the discussion of linked tables:

http://www.utteraccess.com/forum/Beginning-Sql-Server-Deve-t1732935.html
 

mdlueck

Sr. Application Developer
Local time
Today, 04:31
Joined
Jun 23, 2011
Messages
2,631
This is not accurate. JET/ACE is pretty good at sending the SQL back to the server to process if it can. If the query can't be understood by the server, then what you describe will happen.

And I like to focus on gaining experience using reliable technology... no room for shenanigans that "this query was understood but that one is not understood." Pass-Through for ALL queries was my solution... and in fact Stored Procedures (SP) exclusively. Some times executing those with ADO.Command / ADO.Parameter objects, other times using DAO.QueryDef objects configured in Pass-Through mode, and passing in Access / VBA SQL to EXEC the SP on the server. Keeping two ways of executing queries is enough to keep straight in my head.... NO further variations! ;)
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:31
Joined
Aug 30, 2003
Messages
36,128
That's all well and good, but doesn't change the fact that the statement wasn't accurate. It's a common misconception that Access queries will pull all records from a linked SQL Server table, and contributes to IT people's dislike of the product. You appeared to share the misconception, so I wanted to correct it.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 01:31
Joined
Aug 30, 2003
Messages
36,128
Or, you made an inaccurate statement because of your prejudice. ;)

It was inaccurate, as a non-passthrough query will not necessarily "download ALL records from the SQL BE DB and rely on the Access FE DB to sift through the raw data in search of query results".
 

Rx_

Nothing In Moderation
Local time
Today, 02:31
Joined
Oct 22, 2009
Messages
2,803
The guy who posted the question probably got more details than he expected! But, the links both of you provided were very appreciated by me.

Just got back from a meeting to update the new SQL Native Client version. Since I run off a Citrix server, it is necessary to coordinate my development workstation with what is on the Citrix server.

Some new projects that inlcude linking to both Oracle and SQL Server are pending. The more linked tables can be used with simple queries, the better for someone like myself. If MS is right, there should be some improvements for this kind of dual-DB activity.

Thanks for including valuable links.
 

Users who are viewing this thread

Top Bottom