[prev in list] [next in list] [prev in thread] [next in thread]
List: thin
Subject: [THIN] ODBC/bound vs. SQL Procs/unbound with SQL back-end
From: "Toby Bierly" <toby () stahlbush ! com>
Date: 2006-11-30 23:03:39
Message-ID: 028d01c714d3$c62ad7e0$0300000a () stahlbush ! com
[Download RAW message or body]
Perhaps a little OT, but I would love to have some feedback on the pros =
and cons, from a networking perspective, of using ODBC/bound forms vs. =
SQL Stored Procedures/unbound forms when you are using Access as a =
front-end and a SQL Server back-end.
Is the unbound route superior to just linking the SQL tables via ODBC =
and creating bound forms in Access? I am working on a database that =
will be used by 50-100 users once fully rolled out. All the users log =
onto a TS to use the Access front-end. The data sits on a seperate SQL =
Server. I know there are some advantages when using Stored Procedures, =
such as less data needing to be transmitted over the network with Select =
queries. Or if you had multiple different versions of front-ends that =
wrote to the same table, you could help ensure table integrity by =
providing Stored Procedures to Insert/Update data in the table, =
especially if any writes to that table require corresponding writes in =
another table (Transactions). But in this case, it is just one =
front-end being programmed by one person (me), and getting functionality =
added sooner rather than later is a priority.
This is especially true with some existing databases with 30+ forms that =
are all bound forms that my client wants added/integrated into the =
current database that has all unbound forms. I'm thinking I could Upsize =
the tables, and for the most part copy in all the queries, bound forms, =
and bound reports, as well as code from those databases fairly quickly =
compared to totally rewriting the entire database if I had to convert =
everything to unbound forms.
One other question. Currently the database front-ends are stored on the =
TS. My client would like to move them to another server with more =
space. How much additional network traffic would it create to have the =
users logging onto TS to open an Access front-end stored on a 2nd Server =
that is pulling data from 3rd (SQL) Server, as opposed to the front-ends =
being stored directly on the TS? Or would it not really make any =
difference.
All thoughts and feedback appreciated.
Thanks in advance,
Toby
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>
<DIV id=ygrp-text>
<P>
<DIV><FONT face=Arial size=2>Perhaps a little OT, but I would love to have some
feedback on the pros and cons, from a networking perspective, of using
ODBC/bound forms vs. SQL Stored Procedures/unbound forms when you are using
Access as a front-end and a SQL Server back-end.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Is the unbound route superior to just linking
the SQL tables via ODBC and creating bound forms in Access? I am
working on a database that will be used by 50-100 users once
fully rolled out. All the users log onto a TS to use the Access
front-end. The data sits on a seperate SQL Server. I
know there are some advantages when using Stored Procedures, such as less data
needing to be transmitted over the network with Select queries. Or if you
had multiple different versions of front-ends that wrote to the same table, you
could help ensure table integrity by providing Stored Procedures to
Insert/Update data in the table, especially if any writes to that table require
corresponding writes in another table (Transactions)<WBR>. But in this
case, it is just one front-end being programmed by one person (me), and getting
functionality added sooner rather than later is a priority.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This is especially true with some existing
databases with 30+ forms that are all bound forms that my client wants
added/integrated into the current database that has all unbound forms. I'm
thinking I could Upsize the tables, and for the most part copy in all the
queries, bound forms, and bound reports, as well as code from those databases
fairly quickly compared to totally rewriting the entire database if I had to
convert everything to unbound forms.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>One other question. Currently the database
front-ends are stored on the TS. My client would like to move them to
another server with more space. How much additional network traffic would
it create to have the users logging onto TS to open an Access front-end
stored on a 2nd Server that is pulling data from 3rd (SQL) Server, as
opposed to the front-ends being stored directly on the TS? Or would it not
really make any difference.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>All thoughts and feedback appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=Arial size=2>Toby</FONT></DIV></DIV></DIV></BODY></HTML>
SBC SITES ONLY GOOGLE SEARCH: http://www.F1U.com
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://www.freelists.org/list/thin
************************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic