473,372 Members | 1,240 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,372 software developers and data experts.

bizarre asp.net app loading failure

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

Jun 27 '08 #1
8 3104
when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:
We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark
Jun 27 '08 #2
Thanks Bruce... We'll give that a try. Hopefully that will turn something up.

By the by, when do native DllImports() get resolved? When the assembly is
loaded or when some code path need it?

By the other by, I ran into something apparently a number of people have -
running dumpbin.exe doesn't work initially; it needs msvcp80.dll. But if you
copy msvcp80.dll from one of the other VS8 directories into VC\bin,
dumpbin.exe will run but basically everything else craps out after that (IIS
crashes, VS won't build anything, etc). What's up with that?

Thanks
Mark

"bruce barker" wrote:
when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:
We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark
Jun 27 '08 #3
Hi Bruce...

Well, I gave it a try but unfortunately the fusion logs didn't show
anything. I see a bunch of assembly load logs for application 3e70de80
(presumably the name for the app pool). The fusion log for
dtSearchNetApi2.dll says the load was successful; all the assembly loads show
as successful. But then the web page itself blows up saying that
dtSearchNetApi2.dll failed to load.

The test page doesn't reference the assembly at all, so there's not any code
being exercised.

I've never had much luck with Fusion logs; haven't found any useful
information in them.

I did try swapping a bunch of other assemblies in and out of the \bin
directory. It's definitely the dtSearchNetApi2.dll that IIS isn't liking,
but no clue as to why.

Not sure where to look from here.

Thanks
Mark

"bruce barker" wrote:
when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:
We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark
Jun 27 '08 #4
PS - I'm guessing that Depends is not side-by-side component aware, is that
true? On machines where it's working and the one where it's not, a number of
the native dependencies (msvcp80.dll for example) only exists under winsxs.

Presumably the binding is getting served from there, but Depends doesn't
seem to see those when it's reporting missing dlls...

Thanks
Mark
"bruce barker" wrote:
when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:
We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark
Jun 27 '08 #5
Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: =?Utf-8?B?TWFyaw==?= <mm******@nospam.nospam>
References: <C6**********************************@microsoft.co m>
<B1**********************************@microsoft.co m>
>Subject: RE: bizarre asp.net app loading failure
Date: Wed, 11 Jun 2008 14:46:01 -0700
>
PS - I'm guessing that Depends is not side-by-side component aware, is
that
>true? On machines where it's working and the one where it's not, a number
of
>the native dependencies (msvcp80.dll for example) only exists under winsxs.

Presumably the binding is getting served from there, but Depends doesn't
seem to see those when it's reporting missing dlls...

Thanks
Mark
"bruce barker" wrote:
>when an asp.net application starts, all dll's in the bin folder are
loaded.
>most dll's have build references, so this dll's must be loaded. asp.net
is
>different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
-- bruce (sqlwork.com)
"Mark" wrote:
We've got a wierd failure happening on just one machine. One part of
our
product uses a 3rd party search implementation (dtSearch). DtSearch
has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a
couple
of assemblies that reference it, even though they are not used by all
the
applications.

Recently we got an update for dtSearch, which a developer checked in.
For
some reason I can't figure out, it cause the application as deployed
by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly
'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one
of its
dependencies. This application has failed to start because the
application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same
ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our
referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the
new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old
versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I
said,
due to odd packaging the native dten600.dll has never been included
but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for
new
and old dtSearch. The machine in question has never had the msvc?80
dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the
missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use
it) or
why it's just now complaining about not finding some dependencies
where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them
or not?
Any tips at what I should look at next to figure out why it just
started
happening and only on this one machine?

Thanks
Mark
Jun 27 '08 #6
Thanks, Steven...

I'm not that familiar with how things are resolved into the winsxs
hierarchy. I understand it's kind of like the GAC for unmanaged code and
that multiple versions of a dll may be in there, but when the loader is
resolving a dll reference, is it now paying attention to the version linked
to? I'm used to the old dll hell where it picks up the first one it stumbles
over.

One of the things I noticed on this box that's not working is that it
doesn't have a lot of the newer versions of the msvc?80.dlls on it that the
other boxes do. I was wondering if the winsxs system was somehow resolving
versions too, that it might be a mismatch there as well.

The dtSearch unmanaged dll is not present on some machines where IIS is
working, so the only other unmanaged references I could think where having
problems would be the msvc?80.dlls.

Thanks
Mark
"Steven Cheng [MSFT]" wrote:
Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Jun 27 '08 #7
Hi Steven, Bruce...

Figured it out eventually. The problem was that the 3rdparty component was
dependent on newer versions of the CRT than we had on the machine. I wasn't
familiar with the winsxs pre-emption of the path search, so attempts to put
newer versions of dlls in the deploy directory weren't working.

I found a newer vcredist, installed it, and the problem went away.

thanks
Mark
"Steven Cheng [MSFT]" wrote:
Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Jun 27 '08 #8
Thanks for your followup Mark,

I'm glad that you've figured out the issue. So after installing the newer
version of the vc runtime, the side by side system is able to find the
expected version.

BTW, yes, currently windows OS is adding more support for unmanaged dll to
leverage side by side deployment so as to avoid dll hell. And for the
latest visual studio, its unmanaged C++ project will also generate binary
output that add such support(different from old version's outputs). Here
are some articles which may also be helpful:

#Side-by-side Assemblies
http://msdn.microsoft.com/en-us/library/aa376307.aspx

#Why does VC8 install libraries to WinSxS?
http://blogs.msdn.com/martynl/archiv...13/480880.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>Subject: RE: bizarre asp.net app loading failure
Date: Thu, 12 Jun 2008 08:20:00 -0700
>
Hi Steven, Bruce...

Figured it out eventually. The problem was that the 3rdparty component
was
>dependent on newer versions of the CRT than we had on the machine. I
wasn't
>familiar with the winsxs pre-emption of the path search, so attempts to
put
>newer versions of dlls in the deploy directory weren't working.

I found a newer vcredist, installed it, and the problem went away.

thanks
Mark
"Steven Cheng [MSFT]" wrote:
>Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have
use
>PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be
put
>in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion
log
>and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you
tried
>putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally
due
>to some linked dependency of the existing reference that are not found
or
>if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx
Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Jun 27 '08 #9

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

Similar topics

0
by: SPG | last post by:
Hi, We have an applet which is not loading on some systems. We suspect it is a security issue, but cannot be sure as of yet. Is there any way of programatically trapping the failure so we can...
1
by: Craig Graham | last post by:
Don't know which newsgroup this is most suited to. I have a VB.NET app that has been under development for a few months. I have edited some of the Designer-generated code, to replace some...
1
by: Cindy Lee | last post by:
I need to insert rows into MySql database from oracle, which I imagine is a rather common task. The path I decided to take is write a java procedure, as recommended in the manual. However, java...
4
by: The Plankmeister | last post by:
This really is very strange... Have a look at this: http://www.plankmeister.org.uk/new/index.html in IE6. When it loads, the top section is blank. If you mouseover anything in the menu half of...
4
by: nielsonj1976 | last post by:
I am getting a failure on the db backup job of one of my maintenance plans. It is coming back with the generic error message of, "sqlmaint.exe failed. (Error 22029). The step failed." I...
8
by: Snis Pilbor | last post by:
First, let me announce that this is very possibly off-topic because malloc is a specific third party accessory to c, etc. I spent about an hour trying to find a more appropriate newsgroup and...
7
by: R Reyes | last post by:
Can someone please explain to me why I can't get the MS Word Interop assembly to work in my VS2005 project? I'm trying to manipulate MS Word from my Web Form application and I can't get passed...
1
by: zb | last post by:
I am writing a C# program that uses MySQL as database and MySQL ODBC 3.51 driver. It works fine all the way except this scenario that needs to be addressed. 1. Get a set of records to process...
3
by: Leighya | last post by:
Im currently working on this xml file but when i load it to Mozilla, i got an error "Error Loading Stylesheet: Xpath parse failure: invalid variable name" It loads on IE properly. Only with the...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

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.