Windows Server 2003 Problems

[Steve Bishop]

We just migrated a ASP/ADO app over to Windows 2003 Server from a
Windows 2000 machine. We transferred all the includes and .asp Web pages
associated with the app and set up the system DSN to the Access
database. We get intermittent "HTTP 500 - Internal server error Internet
Explorer" messages when we try to hit the login page. When it will let
us in, most of the pages will give us similar errors when trying to
navigate. ASP has been enabled on the 2003 server. This app works fine
on the win2K server and we have been trying to compare settings. Has
anyone ran into a problem like this? Help appreciated.

Steve


*** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
Don't just participate in USENET...get rewarded for it!

[Ray at]

Before you can debug or get help, you'll have to find out what the error is.
[url]http://www.aspfaq.com/show.asp?id=2109[/url]

Ray at home

"Steve Bishop" <steveb@viper.com> wrote in message
news:e47bRfH4DHA.2572@TK2MSFTNGP09.phx.gbl...

>
> We just migrated a ASP/ADO app over to Windows 2003 Server from a
> Windows 2000 machine. We transferred all the includes and .asp Web pages
> associated with the app and set up the system DSN to the Access
> database. We get intermittent "HTTP 500 - Internal server error Internet
> Explorer" messages when we try to hit the login page. When it will let
> us in, most of the pages will give us similar errors when trying to
> navigate. ASP has been enabled on the 2003 server. This app works fine
> on the win2K server and we have been trying to compare settings. Has
> anyone ran into a problem like this? Help appreciated.
>
> Steve
>
>
> *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
> Don't just participate in USENET...get rewarded for it!

[David Morgan]

I don't mean to point out the obvious, but the error you mention below
sounds like the friendly HTTP error IE returns. It masks the real ASP
error. Check Tools - Internet Options - Advanced in IE and un-check show
friendly http errors.

I have not used 2003 but on 2K there was a Send Detailed error message to
the Client setting in the IIS Configuration page for the
website/application. Has that been enhanced in 2003 maybe, giving you that
error.

Sorry if I am totally missing the point here but no one else has responded
and you might be desperate...



"Steve Bishop" <steveb@viper.com> wrote in message
news:e47bRfH4DHA.2572@TK2MSFTNGP09.phx.gbl...

>
> We just migrated a ASP/ADO app over to Windows 2003 Server from a
> Windows 2000 machine. We transferred all the includes and .asp Web pages
> associated with the app and set up the system DSN to the Access
> database. We get intermittent "HTTP 500 - Internal server error Internet
> Explorer" messages when we try to hit the login page. When it will let
> us in, most of the pages will give us similar errors when trying to
> navigate. ASP has been enabled on the 2003 server. This app works fine
> on the win2K server and we have been trying to compare settings. Has
> anyone ran into a problem like this? Help appreciated.
>
> Steve
>
>
> *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
> Don't just participate in USENET...get rewarded for it!

[Steve Bishop]

ASP is enabled on the 2003 Server. could it possibly because the version
of ADO referenced is outdated? Help appreciated.This is the error:
Microsoft OLE DB Provider for ODBC Drivers error '80040e4d'
[Microsoft][ODBC Microsoft Access Driver] Not a valid account name or
password.
/SalesRepPortal/connect.inc, line 8

'This is the connect.inc:
<%@ Language = VBSCRIPT %>
<!-----------------#INCLUDE VIRTUAL="adovbs.inc"--------------->
<!-------------Open Connection String----------------->
<% Dim Connect, Query, rs

Set Connect = Server.CreateObject("ADODB.Connection")
Connect.Open "srp"
%>
'------------------------------
Here is the adovbs.inc:
<XMP><%
'------------------------------
' Microsoft ADO
'
' (c) 1996 Microsoft Corporation. All Rights Reserved.
' ADO constants include file for VBScript

'---- CursorTypeEnum Values ----
Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3

'---- CursorOptionEnum Values ----
Const adHoldRecords = &H00000100
Const adMovePrevious = &H00000200
Const adAddNew = &H01000400
Const adDelete = &H01000800
Const adUpdate = &H01008000
Const adBookmark = &H00002000
Const adApproxPosition = &H00004000
Const adUpdateBatch = &H00010000
Const adResync = &H00020000
Const adNotify = &H00040000

'---- LockTypeEnum Values ----
Const adLockReadOnly = 1
Const adLockPessimistic = 2
Const adLockOptimistic = 3
Const adLockBatchOptimistic = 4

'---- ExecuteOptionEnum Values ----
Const adRunAsync = &H00000010

'---- ObjectStateEnum Values ----
Const adStateClosed = &H00000000
Const adStateOpen = &H00000001
Const adStateConnecting = &H00000002
Const adStateExecuting = &H00000004

'---- CursorLocationEnum Values ----
Const adUseServer = 2
Const adUseClient = 3

'---- DataTypeEnum Values ----
Const adEmpty = 0
Const adTinyInt = 16
Const adSmallInt = 2
Const adInteger = 3
Const adBigInt = 20
Const adUnsignedTinyInt = 17
Const adUnsignedSmallInt = 18
Const adUnsignedInt = 19
Const adUnsignedBigInt = 21
Const adSingle = 4
Const adDouble = 5
Const adCurrency = 6
Const adDecimal = 14
Const adNumeric = 131
Const adBoolean = 11
Const adError = 10
Const adUserDefined = 132
Const adVariant = 12
Const adIDispatch = 9
Const adIUnknown = 13
Const adGUID = 72
Const adDate = 7
Const adDBDate = 133
Const adDBTime = 134
Const adDBTimeStamp = 135
Const adBSTR = 8
Const adChar = 129
Const adVarChar = 200
Const adLongVarChar = 201
Const adWChar = 130
Const adVarWChar = 202
Const adLongVarWChar = 203
Const adBinary = 128
Const adVarBinary = 204
Const adLongVarBinary = 205

'---- FieldAttributeEnum Values ----
Const adFldMayDefer = &H00000002
Const adFldUpdatable = &H00000004
Const adFldUnknownUpdatable = &H00000008
Const adFldFixed = &H00000010
Const adFldIsNullable = &H00000020
Const adFldMayBeNull = &H00000040
Const adFldLong = &H00000080
Const adFldRowID = &H00000100
Const adFldRowVersion = &H00000200
Const adFldCacheDeferred = &H00001000

'---- EditModeEnum Values ----
Const adEditNone = &H0000
Const adEditInProgress = &H0001
Const adEditAdd = &H0002
Const adEditDelete = &H0004

'---- RecordStatusEnum Values ----
Const adRecOK = &H0000000
Const adRecNew = &H0000001
Const adRecModified = &H0000002
Const adRecDeleted = &H0000004
Const adRecUnmodified = &H0000008
Const adRecInvalid = &H0000010
Const adRecMultipleChanges = &H0000040
Const adRecPendingChanges = &H0000080
Const adRecCanceled = &H0000100
Const adRecCantRelease = &H0000400
Const adRecConcurrencyViolation = &H0000800
Const adRecIntegrityViolation = &H0001000
Const adRecMaxChangesExceeded = &H0002000
Const adRecObjectOpen = &H0004000
Const adRecOutOfMemory = &H0008000
Const adRecPermissionDenied = &H0010000
Const adRecSchemaViolation = &H0020000
Const adRecDBDeleted = &H0040000

'---- GetRowsOptionEnum Values ----
Const adGetRowsRest = -1

'---- PositionEnum Values ----
Const adPosUnknown = -1
Const adPosBOF = -2
Const adPosEOF = -3

'---- enum Values ----
Const adBookmarkCurrent = 0
Const adBookmarkFirst = 1
Const adBookmarkLast = 2

'---- MarshalOptionsEnum Values ----
Const adMarshalAll = 0
Const adMarshalModifiedOnly = 1

'---- AffectEnum Values ----
Const adAffectCurrent = 1
Const adAffectGroup = 2
Const adAffectAll = 3

'---- FilterGroupEnum Values ----
Const adFilterNone = 0
Const adFilterPendingRecords = 1
Const adFilterAffectedRecords = 2
Const adFilterFetchedRecords = 3
Const adFilterPredicate = 4

'---- SearchDirection Values ----
Const adSearchForward = 1
Const adSearchBackward = -1

'---- ConnectPromptEnum Values ----
Const adPromptAlways = 1
Const adPromptComplete = 2
Const adPromptCompleteRequired = 3
Const adPromptNever = 4

'---- ConnectModeEnum Values ----
Const adModeUnknown = 0
Const adModeRead = 1
Const adModeWrite = 2
Const adModeReadWrite = 3
Const adModeShareDenyRead = 4
Const adModeShareDenyWrite = 8
Const adModeShareExclusive = &Hc
Const adModeShareDenyNone = &H10

'---- IsolationLevelEnum Values ----
Const adXactUnspecified = &Hffffffff
Const adXactChaos = &H00000010
Const adXactReadUncommitted = &H00000100
Const adXactBrowse = &H00000100
Const adXactCursorStability = &H00001000
Const adXactReadCommitted = &H00001000
Const adXactRepeatableRead = &H00010000
Const adXactSerializable = &H00100000
Const adXactIsolated = &H00100000

'---- XactAttributeEnum Values ----
Const adXactCommitRetaining = &H00020000
Const adXactAbortRetaining = &H00040000

'---- PropertyAttributesEnum Values ----
Const adPropNotSupported = &H0000
Const adPropRequired = &H0001
Const adPropOptional = &H0002
Const adPropRead = &H0200
Const adPropWrite = &H0400

'---- ErrorValueEnum Values ----
Const adErrInvalidArgument = &Hbb9
Const adErrNoCurrentRecord = &Hbcd
Const adErrIllegalOperation = &Hc93
Const adErrInTransaction = &Hcae
Const adErrFeatureNotAvailable = &Hcb3
Const adErrItemNotFound = &Hcc1
Const adErrObjectInCollection = &Hd27
Const adErrObjectNotSet = &Hd5c
Const adErrDataConversion = &Hd5d
Const adErrObjectClosed = &He78
Const adErrObjectOpen = &He79
Const adErrProviderNotFound = &He7a
Const adErrBoundToCommand = &He7b
Const adErrInvalidParamInfo = &He7c
Const adErrInvalidConnection = &He7d
Const adErrStillExecuting = &He7f
Const adErrStillConnecting = &He81

'---- ParameterAttributesEnum Values ----
Const adParamSigned = &H0010
Const adParamNullable = &H0040
Const adParamLong = &H0080

'---- ParameterDirectionEnum Values ----
Const adParamUnknown = &H0000
Const adParamInput = &H0001
Const adParamOutput = &H0002
Const adParamInputOutput = &H0003
Const adParamReturnValue = &H0004

'---- CommandTypeEnum Values ----
Const adCmdUnknown = &H0008
Const adCmdText = &H0001
Const adCmdTable = &H0002
Const adCmdStoredProc = &H0004

'---- SchemaEnum Values ----
Const adSchemaProviderSpecific = -1
Const adSchemaAsserts = 0
Const adSchemaCatalogs = 1
Const adSchemaCharacterSets = 2
Const adSchemaCollations = 3
Const adSchemaColumns = 4
Const adSchemaCheckConstraints = 5
Const adSchemaConstraintColumnUsage = 6
Const adSchemaConstraintTableUsage = 7
Const adSchemaKeyColumnUsage = 8
Const adSchemaReferentialContraints = 9
Const adSchemaTableConstraints = 10
Const adSchemaColumnsDomainUsage = 11
Const adSchemaIndexes = 12
Const adSchemaColumnPrivileges = 13
Const adSchemaTablePrivileges = 14
Const adSchemaUsagePrivileges = 15
Const adSchemaProcedures = 16
Const adSchemaSchemata = 17
Const adSchemaSQLLanguages = 18
Const adSchemaStatistics = 19
Const adSchemaTables = 20
Const adSchemaTranslations = 21
Const adSchemaProviderTypes = 22
Const adSchemaViews = 23
Const adSchemaViewColumnUsage = 24
Const adSchemaViewTableUsage = 25
Const adSchemaProcedureParameters = 26
Const adSchemaForeignKeys = 27
Const adSchemaPrimaryKeys = 28
Const adSchemaProcedureColumns = 29
%>
</XMP>

*** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
Don't just participate in USENET...get rewarded for it!

[Ray at]

You're apparently using a DSN. When you test the DSN, does it work?
Instead of a DSN, how about connecting to your database with oledb.

From [url]www.connectionstrings.com[/url]
Standard security:

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\somepath\mydb.mdb;User
Id=admin;Password=;"



a.. Workgroup (system database):

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\somepath\mydb.mdb;Jet
OLEDB:System Database=system.mdw;"



a.. With password:

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\somepath\mydb.mdb;Jet
OLEDB:Database Password=MyDbPassword;"

Ray at work

"Steve Bishop" <steveb@viper.com> wrote in message
news:%23TGfhpO4DHA.1592@TK2MSFTNGP10.phx.gbl...

> ASP is enabled on the 2003 Server. could it possibly because the version
> of ADO referenced is outdated? Help appreciated.This is the error:
> Microsoft OLE DB Provider for ODBC Drivers error '80040e4d'
> [Microsoft][ODBC Microsoft Access Driver] Not a valid account name or
> password.
> /SalesRepPortal/connect.inc, line 8
>
> 'This is the connect.inc:
> <%@ Language = VBSCRIPT %>
> <!-----------------#INCLUDE VIRTUAL="adovbs.inc"--------------->
> <!-------------Open Connection String----------------->
> <% Dim Connect, Query, rs
>
> Set Connect = Server.CreateObject("ADODB.Connection")
> Connect.Open "srp"
> %>
> '------------------------------
> Here is the adovbs.inc:

<didn't need all that...>

[Aaron Bertrand - MVP]

> Connect.Open "srp"

Ugh, quit using a DSN.

--
Aaron Bertrand
SQL Server MVP
[url]http://www.aspfaq.com/[/url]

[George183]

Steve,

I have ran into the exact same issue. Unfortunately, I have no good news
to report...

Microsoft has been working on this with us and so far we have stumped them
also. Our 2003 server runs about 9 websites. A few of them connect to our
SQL database through DSN-Less asp connections. At times, these connections
work perfectly. Other times, they will fail with errors reported in the
browser such as "800a01fb" VB Errors, or 0242 ASP Errors.

Restarting the IIS Services on the server seem to resolve this issue for a
while. But the problem will eventually creep back up. Not sure how to
proceed, but I have paid the $245 to open a case with Microsoft for
assistance. I will keep you posted on our progress.

Thanks!
DG


"Steve Bishop" <steveb@viper.com> wrote in message
news:e47bRfH4DHA.2572@TK2MSFTNGP09.phx.gbl...

>
> We just migrated a ASP/ADO app over to Windows 2003 Server from a
> Windows 2000 machine. We transferred all the includes and .asp Web pages
> associated with the app and set up the system DSN to the Access
> database. We get intermittent "HTTP 500 - Internal server error Internet
> Explorer" messages when we try to hit the login page. When it will let
> us in, most of the pages will give us similar errors when trying to
> navigate. ASP has been enabled on the 2003 server. This app works fine
> on the win2K server and we have been trying to compare settings. Has
> anyone ran into a problem like this? Help appreciated.
>
> Steve
>
>
> *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
> Don't just participate in USENET...get rewarded for it!

[Aaron Bertrand - MVP]

> browser such as "800a01fb" VB Errors, or 0242 ASP Errors.

Could you be more specific? For the first one, maybe here, but I can't tell
because you forgot to tell us the TEXT of the error message or the code that
causes it.

[url]http://www.aspfaq.com/2327[/url]

[David Morgan]

Yo Aaron... have you been drinking... I see posts with expletives in SQL
Server Programming and then this.

You are oh so quick to disregard the DSN but you are missing one thing that
it provides... SECURITY.

I know it's a while since we've had a "View Source Code" bug, but when they
were around using a DSN protected the login credentials, (and in the case of
MS Access, the location), for your database.

Those storing connection strings in the Global.asa or in db_conn.asp include
files etc are leaving themselves potentially wide open for the next view
source code bug. I know there hasn't been one recently, but back in the day
there were three.




"Aaron Bertrand - MVP" <aaron@TRASHaspfaq.com> wrote in message
news:umgGAtP4DHA.2404@TK2MSFTNGP10.phx.gbl...

> > Connect.Open "srp"

>
> Ugh, quit using a DSN.
>
> --
> Aaron Bertrand
> SQL Server MVP
> [url]http://www.aspfaq.com/[/url]
>
>

[Aaron Bertrand [MVP]]

> I see posts with expletives in SQL Server Programming

Do you have a cite, instead of vague quasi-reference? And could you also
provide for the jury, if your attempt is to sling mud to make me look like
an evil person, the number of posts *without* expletives, so that pointing
out one post doesn't seem so one-sided?

> Those storing connection strings in the Global.asa or in db_conn.asp

include

> files etc are leaving themselves potentially wide open for the next view
> source code bug.

I'm curious why you chose to beat me up about this, when Ray made the exact
same suggestion as I did: drop the DSN.

> I know there hasn't been one recently, but back in the day
> there were three.

I recall one: ::$DATA. And that was so highly publicized that anyone not
patching their servers to protect themselves deserved what they got, IMHO.

If you really think that "obscuring" the database's location using a DSN
protects you, good luck. If I have access to the file system that has the
file that contains the name of the DSN, chances are, I can create my own ASP
file, use your "secure" DSN name, and write code that does whatever the
permissions of the DSN allow me to do. I can also easily derive the
different properties of the DSN:

<%
set conn = CreateObject("ADODB.Connection")
conn.open "Your-Secure-DSN-Name"
response.write conn.properties("Extended Properties")
%>

And I could probably come up with a dozen other ways to get past that
oh-so-secure layer, if I could be bothered. Thankfully, I have better
things to do this evening.

[David Morgan]

Whoa...

It is due to the volume of posts that you have made so expertly and
helpfully that made me wonder, that's all.

I apologise if you feel beaten up over this, but I think anyone reading
"Ugh, drop the DSN", would not have been overly enamoured with your
contribution, when you are normally so verbose and constructive. Ray's
comment was "Instead of a DSN, how about connecting to your database with
oledb". Slightly more welcoming for the ng newbie.

I am not saying that DSNs are secure I am just saying they are more secure
than DSN-less connection strings stored in include files or the global.asa.
It seems to be standard practice to take offence when use of a DSN is
witnessed.

I am trying to be open minded about the differing levels of
experience/expertise that some of the users of the ng will be at and as far
as I can see, the further away from project folders that database
credentials are the better. I do think obscuring the database's location
gives you more protection than not obscuring it. I am amazed that you do not
think the same.

Having knowledge of login credentials for a SQL Server database is enough to
cause damage with out having to upload files that write out ODBC properties
or upload/create anything on the server. As you will appreciate, accessing
the registry or creating files on the server are two big steps from being
able to view files being transmitted to a FTP location with plain text
passwords etc. Whilst I am not interested in a dozen other ways of getting
the information that the DSN obscures I still believe despite the
performance benefits DSN-less connections may give, there is definitely some
value in not storing pertinent information such as user ids, passwords and
database locations along with the website content. In the ISP world where
everyone is sharing servers and access to parent folders etc. is not
available I imagine most people finding the DSN a godsend.

Love your work. Didn't mean to offend.

Regards

David.


"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:evlQgqt4DHA.2580@TK2MSFTNGP11.phx.gbl...

> > I see posts with expletives in SQL Server Programming

>
> Do you have a cite, instead of vague quasi-reference? And could you also
> provide for the jury, if your attempt is to sling mud to make me look like
> an evil person, the number of posts *without* expletives, so that pointing
> out one post doesn't seem so one-sided?
>

> > Those storing connection strings in the Global.asa or in db_conn.asp

> include

> > files etc are leaving themselves potentially wide open for the next view
> > source code bug.

>
> I'm curious why you chose to beat me up about this, when Ray made the

exact

> same suggestion as I did: drop the DSN.
>

> > I know there hasn't been one recently, but back in the day
> > there were three.

>
> I recall one: ::$DATA. And that was so highly publicized that anyone not
> patching their servers to protect themselves deserved what they got, IMHO.
>
> If you really think that "obscuring" the database's location using a DSN
> protects you, good luck. If I have access to the file system that has the
> file that contains the name of the DSN, chances are, I can create my own

ASP

> file, use your "secure" DSN name, and write code that does whatever the
> permissions of the DSN allow me to do. I can also easily derive the
> different properties of the DSN:
>
> <%
> set conn = CreateObject("ADODB.Connection")
> conn.open "Your-Secure-DSN-Name"
> response.write conn.properties("Extended Properties")
> %>
>
> And I could probably come up with a dozen other ways to get past that
> oh-so-secure layer, if I could be bothered. Thankfully, I have better
> things to do this evening.
>
>

[Bob Barrows]

David Morgan wrote:

> I am not saying that DSNs are secure I am just saying they are more
> secure than DSN-less connection strings stored in include files or
> the global.asa. It seems to be standard practice to take offence when
> use of a DSN is witnessed.
>

To me, the main reason to avoid DSN's is the deprecation of the MSDASQL
provider, which is the OLEDB provider which allows ADO to use ODBC data
sources. That means:

1. Someday, you will be unable to use ADO to connect via a DSN. MSDASQL has
been on the deprecated components list for at least two, and possible three
versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who can
say? If it isn't nobody can say that we weren't warned.

2. Functionality will exist in the native OLEDB provider that you will not
get from the ODBC driver.

The performance and robustness gain should not be minimized: by using ODBC,
you are interposing an extra layer of software between your application and
the database, increasing the amount of data that has to be marshalled across
processes and increasing the risk that something may go wrong during the
process.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Aaron Bertrand [MVP]]

But Bob, you're talking crazy talk! If you use a DSN, you can put the
database connection information one step further away from bandits! I hope
you were wearing a tin foil hat while typing your post. :-)

Of course, if you use a DSN-less connection, and you're that worried about
aliens getting into your file system, you couldn't possibly put connection
information into a DLL or some other "more secure" place. No, definitely, a
DSN is the only safe way to guard your database...





"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...

> David Morgan wrote:

> > I am not saying that DSNs are secure I am just saying they are more
> > secure than DSN-less connection strings stored in include files or
> > the global.asa. It seems to be standard practice to take offence when
> > use of a DSN is witnessed.
> >

> To me, the main reason to avoid DSN's is the deprecation of the MSDASQL
> provider, which is the OLEDB provider which allows ADO to use ODBC data
> sources. That means:
>
> 1. Someday, you will be unable to use ADO to connect via a DSN. MSDASQL

has

> been on the deprecated components list for at least two, and possible

three

> versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who can
> say? If it isn't nobody can say that we weren't warned.
>
> 2. Functionality will exist in the native OLEDB provider that you will not
> get from the ODBC driver.
>
> The performance and robustness gain should not be minimized: by using

ODBC,

> you are interposing an extra layer of software between your application

and

> the database, increasing the amount of data that has to be marshalled

across

> processes and increasing the risk that something may go wrong during the
> process.
>
> Bob Barrows
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>
>

[Don Grover]

No Bob's trying to confuse us and find out if we are awake, I had to read
that twice and then your post Aaron to make sure I was awake.
It goes to show that the best of us do make mistakes or at least need more
sleep ;-).

In reference to connection strings in the orginal post, I reccomend putting
conn string in a encrypted private function in a seperate dll called by
passing a server key and server ipnum to a public function and returning
relevant username & pwd.
That combined with only admin and iweb access atleast gives it some
security, but must rember to keep the dll source 8-).

By the way this was on a asp app putting $30-40M a month through it.

Don



"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:ObfGatH5DHA.1816@TK2MSFTNGP12.phx.gbl...

> But Bob, you're talking crazy talk! If you use a DSN, you can put the
> database connection information one step further away from bandits! I

hope

> you were wearing a tin foil hat while typing your post. :-)
>
> Of course, if you use a DSN-less connection, and you're that worried about
> aliens getting into your file system, you couldn't possibly put connection
> information into a DLL or some other "more secure" place. No, definitely,

a

> DSN is the only safe way to guard your database...
>
>
>
>
>
> "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...

> > David Morgan wrote:

> > > I am not saying that DSNs are secure I am just saying they are more
> > > secure than DSN-less connection strings stored in include files or
> > > the global.asa. It seems to be standard practice to take offence when
> > > use of a DSN is witnessed.
> > >

> > To me, the main reason to avoid DSN's is the deprecation of the MSDASQL
> > provider, which is the OLEDB provider which allows ADO to use ODBC data
> > sources. That means:
> >
> > 1. Someday, you will be unable to use ADO to connect via a DSN. MSDASQL

> has

> > been on the deprecated components list for at least two, and possible

> three

> > versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who

can

> > say? If it isn't nobody can say that we weren't warned.
> >
> > 2. Functionality will exist in the native OLEDB provider that you will

not

> > get from the ODBC driver.
> >
> > The performance and robustness gain should not be minimized: by using

> ODBC,

> > you are interposing an extra layer of software between your application

> and

> > the database, increasing the amount of data that has to be marshalled

> across

> > processes and increasing the risk that something may go wrong during the
> > process.
> >
> > Bob Barrows
> >
> > --
> > Microsoft MVP - ASP/ASP.NET
> > Please reply to the newsgroup. This email account is my spam trap so I
> > don't check it very often. If you must reply off-line, then remove the
> > "NO SPAM"
> >
> >

>
>

[Henry Chueh]

Same issue here. Moved ASP app from Windows 2000 server to 2003 server and we
get intermittent hangs in the connection to SQL Server (DSN-less). We don't get any
ASP errors, the IE world just spins forever without coming back! When it works, it
works. When it doesn't, have to restart the IIS application to correct it.

If you get an answer, please post. Thanks, Henry


"George183" <dgeorge@bergeo.biz> wrote in message news:<upvWI9W4DHA.1672@TK2MSFTNGP12.phx.gbl>...

> Steve,
>
> I have ran into the exact same issue. Unfortunately, I have no good news
> to report...
>
> Microsoft has been working on this with us and so far we have stumped them
> also. Our 2003 server runs about 9 websites. A few of them connect to our
> SQL database through DSN-Less asp connections. At times, these connections
> work perfectly. Other times, they will fail with errors reported in the
> browser such as "800a01fb" VB Errors, or 0242 ASP Errors.
>
> Restarting the IIS Services on the server seem to resolve this issue for a
> while. But the problem will eventually creep back up. Not sure how to
> proceed, but I have paid the $245 to open a case with Microsoft for
> assistance. I will keep you posted on our progress.
>
> Thanks!
> DG
>
>
> "Steve Bishop" <steveb@viper.com> wrote in message
> news:e47bRfH4DHA.2572@TK2MSFTNGP09.phx.gbl...

> >
> > We just migrated a ASP/ADO app over to Windows 2003 Server from a
> > Windows 2000 machine. We transferred all the includes and .asp Web pages
> > associated with the app and set up the system DSN to the Access
> > database. We get intermittent "HTTP 500 - Internal server error Internet
> > Explorer" messages when we try to hit the login page. When it will let
> > us in, most of the pages will give us similar errors when trying to
> > navigate. ASP has been enabled on the 2003 server. This app works fine
> > on the win2K server and we have been trying to compare settings. Has
> > anyone ran into a problem like this? Help appreciated.
> >
> > Steve
> >
> >
> > *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
> > Don't just participate in USENET...get rewarded for it!

[David Morgan]

I was not talking about ODBC, I was talking about DSNs. Surely using a
DSN-less connection string is still ODBC.

"Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...

> David Morgan wrote:

> > I am not saying that DSNs are secure I am just saying they are more
> > secure than DSN-less connection strings stored in include files or
> > the global.asa. It seems to be standard practice to take offence when
> > use of a DSN is witnessed.
> >

> To me, the main reason to avoid DSN's is the deprecation of the MSDASQL
> provider, which is the OLEDB provider which allows ADO to use ODBC data
> sources. That means:
>
> 1. Someday, you will be unable to use ADO to connect via a DSN. MSDASQL

has

> been on the deprecated components list for at least two, and possible

three

> versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who can
> say? If it isn't nobody can say that we weren't warned.
>
> 2. Functionality will exist in the native OLEDB provider that you will not
> get from the ODBC driver.
>
> The performance and robustness gain should not be minimized: by using

ODBC,

> you are interposing an extra layer of software between your application

and

> the database, increasing the amount of data that has to be marshalled

across

> processes and increasing the risk that something may go wrong during the
> process.
>
> Bob Barrows
>
> --
> Microsoft MVP - ASP/ASP.NET
> Please reply to the newsgroup. This email account is my spam trap so I
> don't check it very often. If you must reply off-line, then remove the
> "NO SPAM"
>
>

[David Morgan]

You could of course Aaron, but _you_ cited using DSN-less over DSN based.
Now you have gone off at a tangent in an attempt to ridicule, but I am not
the one suggesting DSN-less connections, you are.




"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:ObfGatH5DHA.1816@TK2MSFTNGP12.phx.gbl...

> But Bob, you're talking crazy talk! If you use a DSN, you can put the
> database connection information one step further away from bandits! I

hope

> you were wearing a tin foil hat while typing your post. :-)
>
> Of course, if you use a DSN-less connection, and you're that worried about
> aliens getting into your file system, you couldn't possibly put connection
> information into a DLL or some other "more secure" place. No, definitely,

a

> DSN is the only safe way to guard your database...
>
>
>
>
>
> "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...

> > David Morgan wrote:

> > > I am not saying that DSNs are secure I am just saying they are more
> > > secure than DSN-less connection strings stored in include files or
> > > the global.asa. It seems to be standard practice to take offence when
> > > use of a DSN is witnessed.
> > >

> > To me, the main reason to avoid DSN's is the deprecation of the MSDASQL
> > provider, which is the OLEDB provider which allows ADO to use ODBC data
> > sources. That means:
> >
> > 1. Someday, you will be unable to use ADO to connect via a DSN. MSDASQL

> has

> > been on the deprecated components list for at least two, and possible

> three

> > versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who

can

> > say? If it isn't nobody can say that we weren't warned.
> >
> > 2. Functionality will exist in the native OLEDB provider that you will

not

> > get from the ODBC driver.
> >
> > The performance and robustness gain should not be minimized: by using

> ODBC,

> > you are interposing an extra layer of software between your application

> and

> > the database, increasing the amount of data that has to be marshalled

> across

> > processes and increasing the risk that something may go wrong during the
> > process.
> >
> > Bob Barrows
> >
> > --
> > Microsoft MVP - ASP/ASP.NET
> > Please reply to the newsgroup. This email account is my spam trap so I
> > don't check it very often. If you must reply off-line, then remove the
> > "NO SPAM"
> >
> >

>
>

[David Morgan]

Yes, that's one suggestion, similar to Aaron's DLL idea. I have previously
used the registry. Again, I was only trying to point out that the DSN does
serve purpose over the DSN-less connection string. Despite Bob's ODBC
comments I have failed to see any argument against this. Maybe Aaron should
formulate some reasoning and constructive comment, (as per his usual
contributions), instead of playing the comedian.


"Don Grover" <spamfree@assoft.com.au> wrote in message
news:uwymy7J5DHA.1504@TK2MSFTNGP12.phx.gbl...

> No Bob's trying to confuse us and find out if we are awake, I had to read
> that twice and then your post Aaron to make sure I was awake.
> It goes to show that the best of us do make mistakes or at least need more
> sleep ;-).
>
> In reference to connection strings in the orginal post, I reccomend

putting

> conn string in a encrypted private function in a seperate dll called by
> passing a server key and server ipnum to a public function and returning
> relevant username & pwd.
> That combined with only admin and iweb access atleast gives it some
> security, but must rember to keep the dll source 8-).
>
> By the way this was on a asp app putting $30-40M a month through it.
>
> Don
>
>
>
> "Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
> news:ObfGatH5DHA.1816@TK2MSFTNGP12.phx.gbl...

> > But Bob, you're talking crazy talk! If you use a DSN, you can put the
> > database connection information one step further away from bandits! I

> hope

> > you were wearing a tin foil hat while typing your post. :-)
> >
> > Of course, if you use a DSN-less connection, and you're that worried

about

> > aliens getting into your file system, you couldn't possibly put

connection

> > information into a DLL or some other "more secure" place. No,

definitely,

> a

> > DSN is the only safe way to guard your database...
> >
> >
> >
> >
> >
> > "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> > news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...

> > > David Morgan wrote:
> > > > I am not saying that DSNs are secure I am just saying they are more
> > > > secure than DSN-less connection strings stored in include files or
> > > > the global.asa. It seems to be standard practice to take offence

when

> > > > use of a DSN is witnessed.
> > > >
> > > To me, the main reason to avoid DSN's is the deprecation of the

MSDASQL

> > > provider, which is the OLEDB provider which allows ADO to use ODBC

data

> > > sources. That means:
> > >
> > > 1. Someday, you will be unable to use ADO to connect via a DSN.

MSDASQL

> > has

> > > been on the deprecated components list for at least two, and possible

> > three

> > > versions of MDAC. Will it be included in MDAC 2.9? Probably, but: who

> can

> > > say? If it isn't nobody can say that we weren't warned.
> > >
> > > 2. Functionality will exist in the native OLEDB provider that you will

> not

> > > get from the ODBC driver.
> > >
> > > The performance and robustness gain should not be minimized: by using

> > ODBC,

> > > you are interposing an extra layer of software between your

application

> > and

> > > the database, increasing the amount of data that has to be marshalled

> > across

> > > processes and increasing the risk that something may go wrong during

the

> > > process.
> > >
> > > Bob Barrows
> > >
> > > --
> > > Microsoft MVP - ASP/ASP.NET
> > > Please reply to the newsgroup. This email account is my spam trap so I
> > > don't check it very often. If you must reply off-line, then remove the
> > > "NO SPAM"
> > >
> > >

> >
> >

>
>

[Mark Schupp]

The reason that DSN-less connections are preferred has to do with
performance and the fact that ODBC is now considered obsolete by Microsoft
(will no longer be enhanced). There was a link to an announcement to that
effect posted here some time ago. It is superceded by OLEDB. The current
Microsoft ODBC Drivers are actually a layer on top of ODBC.

That said, I still use DSNs because it is much easier to walk a client
through setting up a DSN with the ODBC Administrator over the phone than it
is to get them to enter the correct DSN-less connection string.

--
Mark Schupp
Head of Development
Integrity eLearning
[url]www.ielearning.com[/url]


"David Morgan" <david@davidmorgan.me.uk> wrote in message
news:ugXQnQ45DHA.2764@TK2MSFTNGP09.phx.gbl...

> Yes, that's one suggestion, similar to Aaron's DLL idea. I have

previously

> used the registry. Again, I was only trying to point out that the DSN

does

> serve purpose over the DSN-less connection string. Despite Bob's ODBC
> comments I have failed to see any argument against this. Maybe Aaron

should

> formulate some reasoning and constructive comment, (as per his usual
> contributions), instead of playing the comedian.
>
>
> "Don Grover" <spamfree@assoft.com.au> wrote in message
> news:uwymy7J5DHA.1504@TK2MSFTNGP12.phx.gbl...

> > No Bob's trying to confuse us and find out if we are awake, I had to

read

> > that twice and then your post Aaron to make sure I was awake.
> > It goes to show that the best of us do make mistakes or at least need

more

> > sleep ;-).
> >
> > In reference to connection strings in the orginal post, I reccomend

> putting

> > conn string in a encrypted private function in a seperate dll called by
> > passing a server key and server ipnum to a public function and returning
> > relevant username & pwd.
> > That combined with only admin and iweb access atleast gives it some
> > security, but must rember to keep the dll source 8-).
> >
> > By the way this was on a asp app putting $30-40M a month through it.
> >
> > Don
> >
> >
> >
> > "Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
> > news:ObfGatH5DHA.1816@TK2MSFTNGP12.phx.gbl...

> > > But Bob, you're talking crazy talk! If you use a DSN, you can put the
> > > database connection information one step further away from bandits! I

> > hope

> > > you were wearing a tin foil hat while typing your post. :-)
> > >
> > > Of course, if you use a DSN-less connection, and you're that worried

> about

> > > aliens getting into your file system, you couldn't possibly put

> connection

> > > information into a DLL or some other "more secure" place. No,

> definitely,

> > a

> > > DSN is the only safe way to guard your database...
> > >
> > >
> > >
> > >
> > >
> > > "Bob Barrows" <reb01501@NOyahoo.SPAMcom> wrote in message
> > > news:e6Pu5dG5DHA.360@TK2MSFTNGP12.phx.gbl...
> > > > David Morgan wrote:
> > > > > I am not saying that DSNs are secure I am just saying they are

more

> > > > > secure than DSN-less connection strings stored in include files or
> > > > > the global.asa. It seems to be standard practice to take offence

> when

> > > > > use of a DSN is witnessed.
> > > > >
> > > > To me, the main reason to avoid DSN's is the deprecation of the

> MSDASQL

> > > > provider, which is the OLEDB provider which allows ADO to use ODBC

> data

> > > > sources. That means:
> > > >
> > > > 1. Someday, you will be unable to use ADO to connect via a DSN.

> MSDASQL

> > > has
> > > > been on the deprecated components list for at least two, and

possible

> > > three
> > > > versions of MDAC. Will it be included in MDAC 2.9? Probably, but:

who

> > can

> > > > say? If it isn't nobody can say that we weren't warned.
> > > >
> > > > 2. Functionality will exist in the native OLEDB provider that you

will

> > not

> > > > get from the ODBC driver.
> > > >
> > > > The performance and robustness gain should not be minimized: by

using

> > > ODBC,
> > > > you are interposing an extra layer of software between your

> application

> > > and
> > > > the database, increasing the amount of data that has to be

marshalled

> > > across
> > > > processes and increasing the risk that something may go wrong during

> the

> > > > process.
> > > >
> > > > Bob Barrows
> > > >
> > > > --
> > > > Microsoft MVP - ASP/ASP.NET
> > > > Please reply to the newsgroup. This email account is my spam trap so

I

> > > > don't check it very often. If you must reply off-line, then remove

the

> > > > "NO SPAM"
> > > >
> > > >
> > >
> > >

> >
> >

>
>

[Aaron Bertrand [MVP]]

> Surely using a

> DSN-less connection string is still ODBC.

Surely, indeed. Unless you specify a connection string that doesn't use
ODBC...

--
Aaron Bertrand
SQL Server MVP
[url]http://www.aspfaq.com/[/url]