personally I don't think it will affect performance either way. All you are
doing is providing a different method of connection to the DB. SQL itself
will handle the connections. The ODBC stuff is separate from the DB after
all. I'm not sure how all this affects CF....wouldn't have thought it made
any difference. I'd choose scenario 2 for sure 'cos there's no point having
2 iddentical DSN's if there are no performance issues. If you find out that
there are could you let me know.....I'd be intruiged, if slightly surprised
and may have to start changing things here!!!
------------------------------------------------------------------
Andrew Ewings
Project Manager
Thoughtbubble Ltd
------------------------------------------------------------------
-----Original Message-----
From: Eric Hoffman [mailto:[EMAIL PROTECTED]]
Sent: 10 October 2000 18:48
To: CF-Talk
Subject: ODBC Datasource Theoretical ?
Which one of these two scenarios would you find to be the most efficient use
of the ODBC connections on a CF server which connects to a SQL box? (we
have a database on a SQL server with 5 separate tables for different apps)
1. Multiple Datasource (one per app) names pointing to a single SQL
database?
2. One datasource shared by all the apps connecting to the single SQL
database?
If you have 15 users connecting at a time, which one leaves CF in the best
shape? I think that #2 is the best answer, but a Net Admin guy here asked
and I wanted to be sure.
Thanks.
Eric
Meagher & Geer, PLLP
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
