473,699 Members | 2,412 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

annoying delay during refresh of aspx web page with ODBC Access query on IIS Windows 2003

Hello All,

I have been working on this for almost a week now and I haven't anything up
my sleeves anymore that I could test in addition or change....
Since I am not sure, if this is a Windows 2003 Server or ADO or ODBC issue,
I am posting this on all of the three newsgroups.

That's the setup:
Windows 2003 Server with IIS and ASP.NET actiavted
Access 2002 mdb file (and yes, proper rights are set on TMP paths and path,
where mdb file is located)
ASP.Net web server component that will query and update the Access DB in the
functionality of a web counter

The problem is, that after the first call of the web site with the web
counter component, the refresh will take about 8-9 seconds. Doesn't matter
if I close the IE or just hit the refresh.

From what I can observe is, that after the start of the IIS web server no
w3wp.exe process is running. As soon as I open the aspx web site with the
..Net built counter component, a w3wp.exe process is being instantiated and
the calls to the Access DB are made. Since the w3wp.exe process has to
start, the inital display of the web page takes about 1-2 seconds and
everything works fine. I can see a .tmp file being created in the TMP
directory and a .ldb file being created in the path of the .mdb file for a
brief moment. Then they disappear. The w3wp.exe process stays. Then, if I
hit refresh or close and reopen the web site, nothing seems to happen for
8-9 seconds and then the page displays without any errors. The difference
is, that the .tmp file and the .ldb file are also sitting in the
corresponding paths for a while longer, but both disappear again.

Since I have been doing quiet a bit of trouble shooting already, here is
some detailed info as of what happens during the inital call of the web
site, and during subsequent calls:

Output of current second and millisecond of the machine during initial call,
when no w3wp.exe process existed yet:
58:343 objCounterDBCon nection = New OdbcConnection
58:359 objCounterDBCom mand = New OdbcCommand
58:359 objCounterDBCon nection.Open()
58:390 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
58:562 objCounterDbRdr .Read
58:562 objCounterDbRdr .Close()
58:578 objCounterDBCon nection.Close()
58:625 preparing insert
58:640 objCounterDBCon nection.Open()
58:640 objCounterDBCom mand.ExecuteNon Query()
58:640 objCounterDBCon nection.Close()
58:687 objCounterDBCon nection & objCounterDBCom mand.Dispose()
58:687 finished

Output of current second and millisecond of the machine during subsequent
call, when existing w3wp.exe process apparently take the job:
10:359 objCounterDBCon nection = New OdbcConnection
10:359 objCounterDBCom mand = New OdbcCommand
10:359 objCounterDBCon nection.Open()
10:375 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
19:140 objCounterDbRdr .Read
19:140 objCounterDbRdr .Close()
19:140 objCounterDBCon nection.Close()
19:187 preparing insert
19:187 objCounterDBCon nection.Open()
19:187 objCounterDBCom mand.ExecuteNon Query()
19:187 objCounterDBCon nection.Close()
19:234 objCounterDBCon nection & objCounterDBCom mand.Dispose()
19:234 finished

As you can see, during a subsequent call, the ExecuteReader takes close to 9
seconds before it returns the OdbcDataReader object.

WHY????

This is not an update and hence has nothing to do with lazy propagation
issues as far as I can tell what I have seen on different posts.
Also, this problem occurs only on the Windows 2003 Server, not the Windows
2000 Server.
What is the issue here? - the initial w3wp.exe process is being run under
the NETWORK SERVICE account and I have given that account proper permissions
to perform the job. That is being verified in my opinion by the fact, that
the first run of the component works fine.
To me this is an absolute issue of Windows 2003 Server and/or ODBC on
Windows 2003 Server.

Is it ODBC, is it the Windows 2003 server? I have no clue.

Your help on that would be really appreciated and I can post the sources if
necessary if somebody else would like to try that out. I'm almost 99.99%
certain that this is a true Windows 2003 Server or ODBC issue that I am just
about ready to open a call with Microsoft on that.
The source is clean as it could be and I have double checked with quiet a
few examples on MSDN and other Tech articels on that.

Yesterday I had the IIS and application part completly removed from the
server, everything cleaned up and started all over with the install. Exact
same results. No other pocesses are running on that machine at all. It's
clean as it could be. So I am really stumbling on that.

Please help!

Thank you,
Wolfgang
Jul 19 '05 #1
11 3756
I have not read everything, but can get you to a point that might help.

1. Get rid of ODBC. It is God-awful slow. Use OleDb instead with a
connection string and avoid the whole DSN and/or ODBC methodology.
2. If you have tons of code in your ASP.NET project, re-architect and move
business code to business layer components. This will reduce heavy JIT
loads.

Another option is "you have outgrown Access." If you database is in the
multiple megs (over 25MB in some cases, more in others), you are ending up
with an inefficient database. Access starts to really puke when it grows,
esp. with web apps.

Note that Windows Server 2003 can reduce overhead, if you have apps in the
proper pools. Since you do not mention multiple apps, this is unlikely the
problem. I mention largely because improper setup of apps can cause Windows
Server 2003 to take its own sweet time.

NOTE: In Whidbey, there is a precompilation option (finally). Unfortunately,
this does not help the immediate problem. I would focus on getting rid of
ODBC and using OleDb and figuring out what code is taking a long time to JIT
compile. Moving some code to business components may reduce load on the app
JITting. This will force some refactoring of code, but it will pay off
rather quickly as the app can JIT business components as needed, rather than
focusing on the entire ASP.NET app.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************** *************** *************** *************** **********
Think Outside the Box!
*************** *************** *************** *************** **********
"Wolfgang Kaml" <ms@no-spam.kaml.com> wrote in message
news:eE******** ******@TK2MSFTN GP10.phx.gbl...
Hello All,

I have been working on this for almost a week now and I haven't anything up my sleeves anymore that I could test in addition or change....
Since I am not sure, if this is a Windows 2003 Server or ADO or ODBC issue, I am posting this on all of the three newsgroups.

That's the setup:
Windows 2003 Server with IIS and ASP.NET actiavted
Access 2002 mdb file (and yes, proper rights are set on TMP paths and path, where mdb file is located)
ASP.Net web server component that will query and update the Access DB in the functionality of a web counter

The problem is, that after the first call of the web site with the web
counter component, the refresh will take about 8-9 seconds. Doesn't matter
if I close the IE or just hit the refresh.

From what I can observe is, that after the start of the IIS web server no
w3wp.exe process is running. As soon as I open the aspx web site with the
.Net built counter component, a w3wp.exe process is being instantiated and
the calls to the Access DB are made. Since the w3wp.exe process has to
start, the inital display of the web page takes about 1-2 seconds and
everything works fine. I can see a .tmp file being created in the TMP
directory and a .ldb file being created in the path of the .mdb file for a
brief moment. Then they disappear. The w3wp.exe process stays. Then, if I
hit refresh or close and reopen the web site, nothing seems to happen for
8-9 seconds and then the page displays without any errors. The difference
is, that the .tmp file and the .ldb file are also sitting in the
corresponding paths for a while longer, but both disappear again.

Since I have been doing quiet a bit of trouble shooting already, here is
some detailed info as of what happens during the inital call of the web
site, and during subsequent calls:

Output of current second and millisecond of the machine during initial call, when no w3wp.exe process existed yet:
58:343 objCounterDBCon nection = New OdbcConnection
58:359 objCounterDBCom mand = New OdbcCommand
58:359 objCounterDBCon nection.Open()
58:390 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
58:562 objCounterDbRdr .Read
58:562 objCounterDbRdr .Close()
58:578 objCounterDBCon nection.Close()
58:625 preparing insert
58:640 objCounterDBCon nection.Open()
58:640 objCounterDBCom mand.ExecuteNon Query()
58:640 objCounterDBCon nection.Close()
58:687 objCounterDBCon nection & objCounterDBCom mand.Dispose()
58:687 finished

Output of current second and millisecond of the machine during subsequent
call, when existing w3wp.exe process apparently take the job:
10:359 objCounterDBCon nection = New OdbcConnection
10:359 objCounterDBCom mand = New OdbcCommand
10:359 objCounterDBCon nection.Open()
10:375 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
19:140 objCounterDbRdr .Read
19:140 objCounterDbRdr .Close()
19:140 objCounterDBCon nection.Close()
19:187 preparing insert
19:187 objCounterDBCon nection.Open()
19:187 objCounterDBCom mand.ExecuteNon Query()
19:187 objCounterDBCon nection.Close()
19:234 objCounterDBCon nection & objCounterDBCom mand.Dispose()
19:234 finished

As you can see, during a subsequent call, the ExecuteReader takes close to 9 seconds before it returns the OdbcDataReader object.

WHY????

This is not an update and hence has nothing to do with lazy propagation
issues as far as I can tell what I have seen on different posts.
Also, this problem occurs only on the Windows 2003 Server, not the Windows
2000 Server.
What is the issue here? - the initial w3wp.exe process is being run under
the NETWORK SERVICE account and I have given that account proper permissions to perform the job. That is being verified in my opinion by the fact, that
the first run of the component works fine.
To me this is an absolute issue of Windows 2003 Server and/or ODBC on
Windows 2003 Server.

Is it ODBC, is it the Windows 2003 server? I have no clue.

Your help on that would be really appreciated and I can post the sources if necessary if somebody else would like to try that out. I'm almost 99.99%
certain that this is a true Windows 2003 Server or ODBC issue that I am just about ready to open a call with Microsoft on that.
The source is clean as it could be and I have double checked with quiet a
few examples on MSDN and other Tech articels on that.

Yesterday I had the IIS and application part completly removed from the
server, everything cleaned up and started all over with the install. Exact
same results. No other pocesses are running on that machine at all. It's
clean as it could be. So I am really stumbling on that.

Please help!

Thank you,
Wolfgang

Jul 19 '05 #2
Hey Cowboy, ;-))

I really do appreciate your feedback.

A few comments:
- The component I have is a most simplistic WebCounter, so there is not much
of an architecture required. I know that this would be a requirement for a
more sophisticated application. My component has only a very few lines of
code and therefore could be an exreme good example for MS to figure out an
eventual ODBC problem on Windows 2003 Server with MS Access.
- Also, the DB is very small and using SQL Server or MSDE would be an
overkill. I know of the limitations of MS Access though and I am far from
reaching that. That's why it has been an even bigger puzzle to my, why
Windows 2003 Server would 'hang' for 8-9 seconds over such an easy issue.

I will follow your suggestion and modify the app to use OleDb and see if it
makes a difference. If it does, then that would be the ultimate proof that
MS has an issue with the Access ODBC driver on Windows 2003 server.

Now, I'd like to know the difference on Odbc versus OleDb and tried
searching MSDN briefly after reading your article. Somebody responded in a
different thread on a newsgroup here, the OldDb sits on top of Odbc, which
after reading the article
http://msdn.microsoft.com/library/de.../html/daag.asp I
know is not true.
So, OleDb is a different way to access a MS Access DB, but are the different
ways explained somewhere? Do you have an article handy somewhere - just in
case? Don't spend time on searching, I can try that too.

I will let you know how things go after tossing Odbc.

Thanks,
Wolfgang

"Cowboy (Gregory A. Beamer)" <No************ @comcast.netNoS pamM> wrote in
message news:%2******** ********@tk2msf tngp13.phx.gbl. ..
I have not read everything, but can get you to a point that might help.

1. Get rid of ODBC. It is God-awful slow. Use OleDb instead with a
connection string and avoid the whole DSN and/or ODBC methodology.
2. If you have tons of code in your ASP.NET project, re-architect and move
business code to business layer components. This will reduce heavy JIT
loads.

Another option is "you have outgrown Access." If you database is in the
multiple megs (over 25MB in some cases, more in others), you are ending up
with an inefficient database. Access starts to really puke when it grows,
esp. with web apps.

Note that Windows Server 2003 can reduce overhead, if you have apps in the
proper pools. Since you do not mention multiple apps, this is unlikely the
problem. I mention largely because improper setup of apps can cause Windows Server 2003 to take its own sweet time.

NOTE: In Whidbey, there is a precompilation option (finally). Unfortunately, this does not help the immediate problem. I would focus on getting rid of
ODBC and using OleDb and figuring out what code is taking a long time to JIT compile. Moving some code to business components may reduce load on the app JITting. This will force some refactoring of code, but it will pay off
rather quickly as the app can JIT business components as needed, rather than focusing on the entire ASP.NET app.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************** *************** *************** *************** **********
Think Outside the Box!
*************** *************** *************** *************** **********
"Wolfgang Kaml" <ms@no-spam.kaml.com> wrote in message
news:eE******** ******@TK2MSFTN GP10.phx.gbl...
Hello All,

I have been working on this for almost a week now and I haven't anything up
my sleeves anymore that I could test in addition or change....
Since I am not sure, if this is a Windows 2003 Server or ADO or ODBC

issue,
I am posting this on all of the three newsgroups.

That's the setup:
Windows 2003 Server with IIS and ASP.NET actiavted
Access 2002 mdb file (and yes, proper rights are set on TMP paths and

path,
where mdb file is located)
ASP.Net web server component that will query and update the Access DB in

the
functionality of a web counter

The problem is, that after the first call of the web site with the web
counter component, the refresh will take about 8-9 seconds. Doesn't matter if I close the IE or just hit the refresh.

From what I can observe is, that after the start of the IIS web server no w3wp.exe process is running. As soon as I open the aspx web site with the .Net built counter component, a w3wp.exe process is being instantiated and the calls to the Access DB are made. Since the w3wp.exe process has to
start, the inital display of the web page takes about 1-2 seconds and
everything works fine. I can see a .tmp file being created in the TMP
directory and a .ldb file being created in the path of the .mdb file for a brief moment. Then they disappear. The w3wp.exe process stays. Then, if I hit refresh or close and reopen the web site, nothing seems to happen for 8-9 seconds and then the page displays without any errors. The difference is, that the .tmp file and the .ldb file are also sitting in the
corresponding paths for a while longer, but both disappear again.

Since I have been doing quiet a bit of trouble shooting already, here is
some detailed info as of what happens during the inital call of the web
site, and during subsequent calls:

Output of current second and millisecond of the machine during initial

call,
when no w3wp.exe process existed yet:
58:343 objCounterDBCon nection = New OdbcConnection
58:359 objCounterDBCom mand = New OdbcCommand
58:359 objCounterDBCon nection.Open()
58:390 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
58:562 objCounterDbRdr .Read
58:562 objCounterDbRdr .Close()
58:578 objCounterDBCon nection.Close()
58:625 preparing insert
58:640 objCounterDBCon nection.Open()
58:640 objCounterDBCom mand.ExecuteNon Query()
58:640 objCounterDBCon nection.Close()
58:687 objCounterDBCon nection & objCounterDBCom mand.Dispose()
58:687 finished

Output of current second and millisecond of the machine during subsequent call, when existing w3wp.exe process apparently take the job:
10:359 objCounterDBCon nection = New OdbcConnection
10:359 objCounterDBCom mand = New OdbcCommand
10:359 objCounterDBCon nection.Open()
10:375 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
19:140 objCounterDbRdr .Read
19:140 objCounterDbRdr .Close()
19:140 objCounterDBCon nection.Close()
19:187 preparing insert
19:187 objCounterDBCon nection.Open()
19:187 objCounterDBCom mand.ExecuteNon Query()
19:187 objCounterDBCon nection.Close()
19:234 objCounterDBCon nection & objCounterDBCom mand.Dispose()
19:234 finished

As you can see, during a subsequent call, the ExecuteReader takes close to 9
seconds before it returns the OdbcDataReader object.

WHY????

This is not an update and hence has nothing to do with lazy propagation
issues as far as I can tell what I have seen on different posts.
Also, this problem occurs only on the Windows 2003 Server, not the

Windows 2000 Server.
What is the issue here? - the initial w3wp.exe process is being run under the NETWORK SERVICE account and I have given that account proper

permissions
to perform the job. That is being verified in my opinion by the fact, that the first run of the component works fine.
To me this is an absolute issue of Windows 2003 Server and/or ODBC on
Windows 2003 Server.

Is it ODBC, is it the Windows 2003 server? I have no clue.

Your help on that would be really appreciated and I can post the sources

if
necessary if somebody else would like to try that out. I'm almost 99.99%
certain that this is a true Windows 2003 Server or ODBC issue that I am

just
about ready to open a call with Microsoft on that.
The source is clean as it could be and I have double checked with quiet a few examples on MSDN and other Tech articels on that.

Yesterday I had the IIS and application part completly removed from the
server, everything cleaned up and started all over with the install. Exact same results. No other pocesses are running on that machine at all. It's
clean as it could be. So I am really stumbling on that.

Please help!

Thank you,
Wolfgang


Jul 19 '05 #3
Gregory,

THANK YOU so much for the hint. I have thought about using OleDb before, but
wouldn't have given it a try for a long time because I never thought that
Microsoft would have in fact a buggy ODBC setup on Windows 2003 Server.

Everybody using ODBC on Windows 2003 Server with a MS Access DB - and
specially _Microsoft_ - listen up:

With this example, I confirmed the ODBC data connection to MS Access on
Windows 2003 Server to have a bug.

Have a good look at this code example:

Example 1 - using OleDb - takes 1 second on Windows 2003 Server with MS
Access, on _every_ call
'---------------------------------------------------------------------------
------------------------------------
Dim objCounterDBCon nection As OleDbConnection
Dim objCounterDbRdr As OleDbDataReader
Dim objCounterDBCom mand As OleDbCommand

objCounterDBCon nection = New
OleDbConnection ("Provider=Micr osoft.Jet.OLEDB .4.0; Data Source=C:\mydb. mdb")
objCounterDBCom mand = New OleDbCommand("s elect count(*) from [COUNTER] where
CNTPAGE = " & Me.CounterID, objCounterDBCon nection)

Try
objCounterDBCon nection.Open()
objCounterDbRdr =
objCounterDBCom mand.ExecuteRea der(CommandBeha vior.SingleRow)
While objCounterDbRdr .Read
If Not IsDBNull(objCou nterDbRdr.Item( 0)) Then strReturnValue =
objCounterDbRdr .Item(0)
End While
objCounterDbRdr .Close()
objCounterDBCon nection.Close()
Catch ex As Exception
End Try

objCounterDBCom mand.Dispose
objCounterDBCon nection.Dispose

Example 2 - using ODBC - takes 1 second on Windows 2003 Server with MS
Access on the 1st call, and 8.9 seconds on every subsequent call.
'---------------------------------------------------------------------------
------------------------------------
Dim objCounterDBCon nection As OdbcDbConnectio n
Dim objCounterDbRdr As OdbcDbDataReade r
Dim objCounterDBCom mand As OdbcDbCommand

objCounterDBCon nection = New OdbcDbConnectio n("PageTimeout= 5;FIL=MS
Access;MaxBuffe rSize=2048;DSN= MyDSN;UID=admin ;DriverId=25")
objCounterDBCom mand = New OdbcDbCommand(" select count(*) from [COUNTER]
where CNTPAGE = " & Me.CounterID, objCounterDBCon nection)

Try
objCounterDBCon nection.Open()
objCounterDbRdr =
objCounterDBCom mand.ExecuteRea der(CommandBeha vior.SingleRow)
While objCounterDbRdr .Read
If Not IsDBNull(objCou nterDbRdr.Item( 0)) Then strReturnValue =
objCounterDbRdr .Item(0)
End While
objCounterDbRdr .Close()
objCounterDBCon nection.Close()
Catch ex As Exception
End Try

objCounterDBCom mand.Dispose
objCounterDBCon nection.Dispose

'---------------------------------------------------------------------------
------------------------------------

Dear MS folks,
That's what I call a real bug! Please check it and fix it, or drop ODBC
support on Windows 2003 server, because it is a hassle.

Best Regards,
Wolfgang


"Wolfgang Kaml" <ms@no-spam.kaml.com> wrote in message
news:eT******** ******@TK2MSFTN GP10.phx.gbl...
Hey Cowboy, ;-))

I really do appreciate your feedback.

A few comments:
- The component I have is a most simplistic WebCounter, so there is not much of an architecture required. I know that this would be a requirement for a
more sophisticated application. My component has only a very few lines of
code and therefore could be an exreme good example for MS to figure out an
eventual ODBC problem on Windows 2003 Server with MS Access.
- Also, the DB is very small and using SQL Server or MSDE would be an
overkill. I know of the limitations of MS Access though and I am far from
reaching that. That's why it has been an even bigger puzzle to my, why
Windows 2003 Server would 'hang' for 8-9 seconds over such an easy issue.

I will follow your suggestion and modify the app to use OleDb and see if it makes a difference. If it does, then that would be the ultimate proof that
MS has an issue with the Access ODBC driver on Windows 2003 server.

Now, I'd like to know the difference on Odbc versus OleDb and tried
searching MSDN briefly after reading your article. Somebody responded in a
different thread on a newsgroup here, the OldDb sits on top of Odbc, which
after reading the article
http://msdn.microsoft.com/library/de.../html/daag.asp I know is not true.
So, OleDb is a different way to access a MS Access DB, but are the different ways explained somewhere? Do you have an article handy somewhere - just in
case? Don't spend time on searching, I can try that too.

I will let you know how things go after tossing Odbc.

Thanks,
Wolfgang

"Cowboy (Gregory A. Beamer)" <No************ @comcast.netNoS pamM> wrote in
message news:%2******** ********@tk2msf tngp13.phx.gbl. ..
I have not read everything, but can get you to a point that might help.

1. Get rid of ODBC. It is God-awful slow. Use OleDb instead with a
connection string and avoid the whole DSN and/or ODBC methodology.
2. If you have tons of code in your ASP.NET project, re-architect and move
business code to business layer components. This will reduce heavy JIT
loads.

Another option is "you have outgrown Access." If you database is in the
multiple megs (over 25MB in some cases, more in others), you are ending up with an inefficient database. Access starts to really puke when it grows, esp. with web apps.

Note that Windows Server 2003 can reduce overhead, if you have apps in the proper pools. Since you do not mention multiple apps, this is unlikely the problem. I mention largely because improper setup of apps can cause Windows
Server 2003 to take its own sweet time.

NOTE: In Whidbey, there is a precompilation option (finally).

Unfortunately,
this does not help the immediate problem. I would focus on getting rid of ODBC and using OleDb and figuring out what code is taking a long time to

JIT
compile. Moving some code to business components may reduce load on the

app
JITting. This will force some refactoring of code, but it will pay off
rather quickly as the app can JIT business components as needed, rather

than
focusing on the entire ASP.NET app.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************** *************** *************** *************** **********
Think Outside the Box!
*************** *************** *************** *************** **********
"Wolfgang Kaml" <ms@no-spam.kaml.com> wrote in message
news:eE******** ******@TK2MSFTN GP10.phx.gbl...
Hello All,

I have been working on this for almost a week now and I haven't anything
up
my sleeves anymore that I could test in addition or change....
Since I am not sure, if this is a Windows 2003 Server or ADO or ODBC

issue,
I am posting this on all of the three newsgroups.

That's the setup:
Windows 2003 Server with IIS and ASP.NET actiavted
Access 2002 mdb file (and yes, proper rights are set on TMP paths and

path,
where mdb file is located)
ASP.Net web server component that will query and update the Access DB
in the
functionality of a web counter

The problem is, that after the first call of the web site with the web
counter component, the refresh will take about 8-9 seconds. Doesn't matter if I close the IE or just hit the refresh.

From what I can observe is, that after the start of the IIS web server no w3wp.exe process is running. As soon as I open the aspx web site with the .Net built counter component, a w3wp.exe process is being instantiated and the calls to the Access DB are made. Since the w3wp.exe process has to
start, the inital display of the web page takes about 1-2 seconds and
everything works fine. I can see a .tmp file being created in the TMP
directory and a .ldb file being created in the path of the .mdb file
for a brief moment. Then they disappear. The w3wp.exe process stays. Then,
if
I hit refresh or close and reopen the web site, nothing seems to happen for 8-9 seconds and then the page displays without any errors. The difference is, that the .tmp file and the .ldb file are also sitting in the
corresponding paths for a while longer, but both disappear again.

Since I have been doing quiet a bit of trouble shooting already, here
is some detailed info as of what happens during the inital call of the web site, and during subsequent calls:

Output of current second and millisecond of the machine during initial call,
when no w3wp.exe process existed yet:
58:343 objCounterDBCon nection = New OdbcConnection
58:359 objCounterDBCom mand = New OdbcCommand
58:359 objCounterDBCon nection.Open()
58:390 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
58:562 objCounterDbRdr .Read
58:562 objCounterDbRdr .Close()
58:578 objCounterDBCon nection.Close()
58:625 preparing insert
58:640 objCounterDBCon nection.Open()
58:640 objCounterDBCom mand.ExecuteNon Query()
58:640 objCounterDBCon nection.Close()
58:687 objCounterDBCon nection & objCounterDBCom mand.Dispose()
58:687 finished

Output of current second and millisecond of the machine during

subsequent call, when existing w3wp.exe process apparently take the job:
10:359 objCounterDBCon nection = New OdbcConnection
10:359 objCounterDBCom mand = New OdbcCommand
10:359 objCounterDBCon nection.Open()
10:375 objCounterDbRdr = objCounterDBCom mand.ExecuteRea der
19:140 objCounterDbRdr .Read
19:140 objCounterDbRdr .Close()
19:140 objCounterDBCon nection.Close()
19:187 preparing insert
19:187 objCounterDBCon nection.Open()
19:187 objCounterDBCom mand.ExecuteNon Query()
19:187 objCounterDBCon nection.Close()
19:234 objCounterDBCon nection & objCounterDBCom mand.Dispose()
19:234 finished

As you can see, during a subsequent call, the ExecuteReader takes close to
9
seconds before it returns the OdbcDataReader object.

WHY????

This is not an update and hence has nothing to do with lazy
propagation issues as far as I can tell what I have seen on different posts.
Also, this problem occurs only on the Windows 2003 Server, not the
Windows 2000 Server.
What is the issue here? - the initial w3wp.exe process is being run under the NETWORK SERVICE account and I have given that account proper

permissions
to perform the job. That is being verified in my opinion by the fact, that the first run of the component works fine.
To me this is an absolute issue of Windows 2003 Server and/or ODBC on
Windows 2003 Server.

Is it ODBC, is it the Windows 2003 server? I have no clue.

Your help on that would be really appreciated and I can post the sources if
necessary if somebody else would like to try that out. I'm almost
99.99% certain that this is a true Windows 2003 Server or ODBC issue that I am
just
about ready to open a call with Microsoft on that.
The source is clean as it could be and I have double checked with

quiet a few examples on MSDN and other Tech articels on that.

Yesterday I had the IIS and application part completly removed from
the server, everything cleaned up and started all over with the install.

Exact same results. No other pocesses are running on that machine at all. It's clean as it could be. So I am really stumbling on that.

Please help!

Thank you,
Wolfgang



Jul 19 '05 #4
Wolfgang Kaml wrote:
Dear MS folks,
That's what I call a real bug! Please check it and fix it, or drop
ODBC
support on Windows 2003 server, because it is a hassle.


ODBC has been on the Deprecated Components list for at least 2, and possibly
3 versions of MDAC
(http://msdn.microsoft.com/library/en...eprecated.asp).
Unfortunately, the word has not made it to the rank and file. Too many books
have been written in the past 10 yrs using the obsolete technology, and
beginners are still reading those books. There's nobody to tell these
readers that the information in their books is obsolete.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Jul 19 '05 #5
3 more interesting things here:

1) I did some more testing on the ODBC vs. OLEDB part and found out, that
without using DSN but referencing the file name directly in the ODBC code,
the ODBC version is just as fast as OLEDB. It's DSN that's causing the
problem.

2) I just worked for a while with Crystal Reports and the only way you can
connect to an Access DB is using a DSN. Interesting to watch: Microsoft is
making ODBC obsolete, but making a product, that's using ODBC to connect to
their database 'de-facto' standard and ships it with their own product
(refering to Crystal Reports for VS.NET). A good idea for MS would have been
to just buy that company, because they are changing their name so fast, it's
hard to keep track of them. But my appology, put that on a different note
....

3) - And that's actually the most important _QUESTION_ here:
You are linking to a very good article. I am not sure if I am understanding
everything correct that's being said on that but...
- Is Microsoft now calling their MS Jet OLE DB provider obsolete as well? -
In other words, will they drop supporting MS Access?

Thank you,
Wolfgang
"Bob Barrows" <re******@NOyah oo.SPAMcom> wrote in message
news:%2******** **********@TK2M SFTNGP12.phx.gb l...
Wolfgang Kaml wrote:
Dear MS folks,
That's what I call a real bug! Please check it and fix it, or drop
ODBC
support on Windows 2003 server, because it is a hassle.

ODBC has been on the Deprecated Components list for at least 2, and

possibly 3 versions of MDAC
(http://msdn.microsoft.com/library/en...eprecated.asp).
Unfortunately, the word has not made it to the rank and file. Too many books have been written in the past 10 yrs using the obsolete technology, and
beginners are still reading those books. There's nobody to tell these
readers that the information in their books is obsolete.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Jul 19 '05 #6
Hi Wolfgang,

I agree with Cowboy that we may try JET and OLEDB instead. With ODBC, it
will use Access ODBC driver; With OLE DB. it will use JET provider. If
there is something with the ODBC driver, OLEDB may give a better result.
Additionally, what is the version of your Access database? You may perform
a Compact Operation on the database or create a new database instead.
Sometime, a corrupted database also can cause such a problem.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Jul 19 '05 #7
Wolfgang Kaml wrote:
2) I just worked for a while with Crystal Reports and the only way
you can connect to an Access DB is using a DSN. Interesting to watch:
Microsoft is making ODBC obsolete, but making a product, that's using
ODBC to connect to their database 'de-facto' standard and ships it
with their own product (refering to Crystal Reports for VS.NET). A
good idea for MS would have been to just buy that company, because
they are changing their name so fast, it's hard to keep track of
them.


You don't need to use a DSN to make a connection from a Crystal Report.

HTH,
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"
Jul 19 '05 #8
Hi Wolfgang,

Thank you for using the community.

Regarding the questions:

1. With DSN name, it will use MSDASQL provider to access the DSN. It seems
to be the root cause for the problem.
2. Crystal report can use many resource as data source of a report. For
example, ODBC, ADO, OLEDB and even the DataSet in ADO.NET
3. Access and JET is fully support normally. Recenetly the newest JET 4.0
service pack is released.

Hope this help,

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Jul 19 '05 #9
Hi Wolfgang,

I found something really confused. Did you work with ODBC .NET Managed
Provider? For more information about ODBC .NET Managed Provider, you may
refer to:

HOW TO: Use the ODBC .NET Managed Provider in Visual Basic .NET and
Connection Strings
http://support.microsoft.com/default...;EN-US;Q310985

With

ODBC .NET Managed Provider, we define the connection and Command like:

Dim objCounterDBCon nection As OdbcConnection
Dim objCounterDbRdr As OdbcDataReader
Dim objCounterDBCom mand As OdbcCommand

However, in your code:

Dim objCounterDBCon nection As OdbcDbConnectio n
Dim objCounterDbRdr As OdbcDbDataReade r
Dim objCounterDBCom mand As OdbcDbCommand
Did you have "Imports System.Data.Odb c" in your code?

By the way, I have tested your code with ODBC .NET Managed Provider, I
haven't found same problem as you descripted. The access database is an
Access 97 database and I use Microsoft Access Driver to build the system
DSN. Therefore, I think it is too early to tell it is a bug.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Jul 19 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
3138
by: ree | last post by:
For some reason I can't pin point, it is just bugging me like hell. <% dim strQuery strQuery = "UPDATE Gifts SET" strQuery = strQuery & " GuestSelected = " & cint(guestID) strQuery = strQuery & ", DateSelected = " & Now() strQuery = strQuery & " WHERE GiftID = " & selectGiftID' & ";"
13
3802
by: Wolfgang Kaml | last post by:
Hello All, I have been researching newsgroups and knowledgebase all morning and not found a solution that would solve the problem I have. I am having an ASP or ASPX web page that implement a counter functionality and read/insert some data in a MS Access database on that Windows 2003 server. The weird part is, as long as the web page is very short in size, I can hit the refresh button and Internet Explorer will reload the page and display...
11
17562
by: DJJ | last post by:
I am using the MySQL ODBC 3.51 driver to link three relatively small MySQL tables to a Microsoft Access 2003 database. I am finding that the data from the MySQL tables takes a hell of a long time to load making any kind linkage with my Access data virtually useless. I have the MySQL driver setup in as a USER DSN. The MySQL data is sitting out on a server and the Access database is running locally. The network connection is very...
6
7241
by: adish11 | last post by:
Hi, In Web Application I would like to create delay for 30 sec in the code to enable external process to run. During the delay in application I would like to show the user message like "Please wait while the data being updated..." Can u help me please with code lines? Thank u very much for the help and the answer.
10
2763
by: Wolfgang Kaml | last post by:
Hello All, I have been working on this for almost a week now and I haven't anything up my sleeves anymore that I could test in addition or change.... Since I am not sure, if this is a Windows 2003 Server or ADO or ODBC issue, I am posting this on all of the three newsgroups. That's the setup: Windows 2003 Server with IIS and ASP.NET actiavted Access 2002 mdb file (and yes, proper rights are set on TMP paths and path,
7
2937
by: mfeingold | last post by:
I am working on a system, which among other things includes a server and a ..net control sitting in an html page and connected to the server. I ran into a couple of problems, you guys might have some insight about. 1) It takes 20 sec or so to open a tcp socket from the client to the server. It just sits in the TcpClient.conect waiting for something. When I run the same control from a windows application it connects right away and works...
16
9184
by: network-admin | last post by:
We have Problems with Access query on Oracle 10g Database with ODBC Connection. The Query_1 is such as select * from xtable where ycolumn <"S" Result = ODBC Faild ----------------------------------------------------
2
1782
by: =?Utf-8?B?d2R1ZGVr?= | last post by:
I have a website using windows integrated security, with anonymous access turned off. The site is used to query orders from a database and when the search takes a long time, a windows login box appears. Regardless of what login the user enters into this, it does not accept it and the user is locked out of the system. Our network team and myself have been unable to find out why this is occurring, has anyone else had a similiar problem?...
0
8697
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9184
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8892
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7767
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6538
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5878
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4382
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
2
2359
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2013
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.