PacketSize

I am getting the error:
"General network error. Check your network documentation."
It occurrs when I write/update to MSDE 2000 using ADO.NET's SqlClient classe
s. It only occurrs when the record reaches a certain size (around 10K, or s
o) and only occurs in certain environments. Some XP and some Windows 2000 e
nvironments are OK, while o
thers give the error.
I am aware of the PacketSize property in the SqlConnection class, but as of
yet have not set it and have just relied on the default value.
I feel there is something in the .NET or the ADO providers' environment or c
onfigurations that I am not aware of, and would appreciate any help in this
regard.Perhaps try turning off connection pooling (229564)
Bern
"Paul Wicks" <paulwicks@.htninc.com> wrote in message
news:6BAB551B-AC85-4D1C-8B41-89A79A719C81@.microsoft.com...
> I am getting the error:
> "General network error. Check your network documentation."
> It occurrs when I write/update to MSDE 2000 using ADO.NET's SqlClient
classes. It only occurrs when the record reaches a certain size (around
10K, or so) and only occurs in certain environments. Some XP and some
Windows 2000 environments are OK, while others give the error.
> I am aware of the PacketSize property in the SqlConnection class, but as
of yet have not set it and have just relied on the default value.
> I feel there is something in the .NET or the ADO providers' environment or
configurations that I am not aware of, and would appreciate any help in this
regard.
>|||Thanks for your suggestion, Bern.
I wish I could report good news, but the disabling of SQL Server connection
pooling had no effect.
I think I will leave it disabled to avoid possible future complications.

PacketSize

I am getting the error:
"General network error. Check your network documentation."
It occurrs when I write/update to MSDE 2000 using ADO.NET's SqlClient classes. It only occurrs when the record reaches a certain size (around 10K, or so) and only occurs in certain environments. Some XP and some Windows 2000 environments are OK, while o
thers give the error.
I am aware of the PacketSize property in the SqlConnection class, but as of yet have not set it and have just relied on the default value.
I feel there is something in the .NET or the ADO providers' environment or configurations that I am not aware of, and would appreciate any help in this regard.
Perhaps try turning off connection pooling (229564)
Bern
"Paul Wicks" <paulwicks@.htninc.com> wrote in message
news:6BAB551B-AC85-4D1C-8B41-89A79A719C81@.microsoft.com...
> I am getting the error:
> "General network error. Check your network documentation."
> It occurrs when I write/update to MSDE 2000 using ADO.NET's SqlClient
classes. It only occurrs when the record reaches a certain size (around
10K, or so) and only occurs in certain environments. Some XP and some
Windows 2000 environments are OK, while others give the error.
> I am aware of the PacketSize property in the SqlConnection class, but as
of yet have not set it and have just relied on the default value.
> I feel there is something in the .NET or the ADO providers' environment or
configurations that I am not aware of, and would appreciate any help in this
regard.
>
|||Thanks for your suggestion, Bern.
I wish I could report good news, but the disabling of SQL Server connection pooling had no effect.
I think I will leave it disabled to avoid possible future complications.

packaging MSDE 2000 with PDW

How can i package MSDE 2000 (not MSDE 7) with my application using package and deployment wizard?
Burlar:
I have been on this list for a year and installing MSDE with an application
has been the number one problem since then.
As far as I know, it cannot be done reliably.
Paul
"Burlar" <bolanoble@.yahoo.com> wrote in message
news:0E323F53-0F9E-47AB-84A5-70705257E508@.microsoft.com...
> How can i package MSDE 2000 (not MSDE 7) with my application using package
and deployment wizard?
|||Paul,
Then how have you been able to solve the problem. I don't want to have to install msde on every target machine. I feel it is bad practice.
|||Burlar:
I haven't. I am rolling out my app. in a month and seriously considering
telling
users that they must be on Win 2K or above as this will solve a lot of
problems
apparently ...
Paul
"Burlar" <anonymous@.discussions.microsoft.com> wrote in message
news:2B577F83-7918-4F82-ACCA-442C7F4F3C42@.microsoft.com...
> Paul,
> Then how have you been able to solve the problem. I don't want to have to
install msde on every target machine. I feel it is bad practice.
|||Hi Burlar,
In addtion to Paul's advice, check out my comments to anaximan (in this
folder) regarding the PDW. It should now not be being used.
HTH,
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Burlar" <bolanoble@.yahoo.com> wrote in message
news:0E323F53-0F9E-47AB-84A5-70705257E508@.microsoft.com...
> How can i package MSDE 2000 (not MSDE 7) with my application using package
and deployment wizard?

Overcoming the workload limitations of MSDE

Hi
The following topic deals with editing SQLBOOT.DLL by using a
hexadecimal editor
so we can disable workload Governor. Is it true?
Pls comment
http://groups.google.com/group/micro...qlserver.msde/
browse_thread/thread/d364f0edf9b0e6a0/2b1fa848ad052037?
q=limitations&rnum=4#2b1fa848ad052037
regards
Dil
hi,
Dil wrote:
> Hi
> The following topic deals with editing SQLBOOT.DLL by using a
> hexadecimal editor
> so we can disable workload Governor. Is it true?
> Pls comment
> http://groups.google.com/group/micro...qlserver.msde/
> browse_thread/thread/d364f0edf9b0e6a0/2b1fa848ad052037?
> q=limitations&rnum=4#2b1fa848ad052037
as you can immagine, this is not only not supported at all, but would break
your restricted EULA as you are personally patching/hacking a known software
limitation (not a bug) of a product to perform other then inteded...
personally, I'd not...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Thnx once again Andrea,
bye
Dil

Overcoming the connection limitations of MSDE....

I have a Windows application I have developed in VB using a MSDE
database. I will be distributing this to clients, most of which will
have only about 2-4 terminals, but there are many that will have 10-15
terminals running my application. I am afraid of what the performance
is going to be like with clients running a high number of terminals
because of the limitations of MSDE. I looked into the price of the
full version of SQL server for clients with a larger number of
terminals but it would cost way to much so that simply is not an
option for any of them.
I have spoken to other companies who develop products like mine and
they say they have clients running close to 30 terminals off of MSDE
with no slow down. They say they have done this by using connection
pooling. I have looked around on this issue and most people post
articles on connection pooling and the MSDE workload governor but I
have not seen any practical examples on specifically how to setup a
client application to overcome the MSDE workload limit.
As far as connection pooling is concerned, how exactly will this help
in limiting the workload? Does anyone have an specific examples of
how I would do this? I don't want to keep looking around and having
to experiment around with things that may or may not work because I
have no real way of testing this other than giving it to clients to
test. I'd really like to see an actual example of how someone has
done specifically what I'm doing here and has gotten it to work. I'm
surprised there are not more articles on this specific subject, but I
could not find any.
Any help would be appreciated, thanks...
On 15 Apr 2004 08:45:47 -0700, bostonpartykid@.yahoo.com (Ray Lavelle)
wrote:

>I have a Windows application I have developed in VB using a MSDE
>database. I will be distributing this to clients, most of which will
>have only about 2-4 terminals, but there are many that will have 10-15
>terminals running my application. I am afraid of what the performance
>is going to be like with clients running a high number of terminals
>because of the limitations of MSDE. I looked into the price of the
>full version of SQL server for clients with a larger number of
>terminals but it would cost way to much so that simply is not an
>option for any of them.
>I have spoken to other companies who develop products like mine and
>they say they have clients running close to 30 terminals off of MSDE
>with no slow down. They say they have done this by using connection
>pooling. I have looked around on this issue and most people post
>articles on connection pooling and the MSDE workload governor but I
>have not seen any practical examples on specifically how to setup a
>client application to overcome the MSDE workload limit.
>As far as connection pooling is concerned, how exactly will this help
>in limiting the workload? Does anyone have an specific examples of
>how I would do this? I don't want to keep looking around and having
>to experiment around with things that may or may not work because I
>have no real way of testing this other than giving it to clients to
>test. I'd really like to see an actual example of how someone has
>done specifically what I'm doing here and has gotten it to work. I'm
>surprised there are not more articles on this specific subject, but I
>could not find any.
>Any help would be appreciated, thanks...
Don't keep your connection open. Open a connection, get the desired
data and then close the connection. Open a connection, update/insert
the desired data and then close the connection. If your app doesn't
do really intensive data access and you aren't keeping the connection
open, chances of having more than 5 users hit the DB at the same time
are pretty slim.
HTH,
Bryan
__________________________________________________ __________
New Vision Software "When the going gets weird,"
Bryan Stafford "the weird turn pro."
alpine_don'tsendspam@.mvps.org Hunter S. Thompson -
Microsoft MVP-Visual Basic Fear and Loathing in LasVegas
|||hi Ray,
"Ray Lavelle" <bostonpartykid@.yahoo.com> ha scritto nel messaggio
news:d8653140.0404150745.2f9911ec@.posting.google.c om...
> I have a Windows application I have developed in VB using a MSDE
> database. I will be distributing this to clients, most of which will
> have only about 2-4 terminals, but there are many that will have 10-15
> terminals running my application.
> CUT
as Bryan already pointed out, keep your transactions as short as possible...
it's not a matter of connections, becouse users are "usually" idle, and
connection pooling is on by default, but can be not that useful, becouse
connections in the pool can be reused only if the connection string is exact
the same as the last used...
but, again, keep your batches as short as possible.
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.7.0 - DbaMgr ver 0.53.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Ray I have one question though about your scenario as I am in the same boat as you are...
How do you plan to deploy your app with MSDE. I know Microsoft has dismissed merge modules way and is advising the bootstrapper. I am still investigating the bootstrapper but was wondering how will you be setting up your desktop app (I believe it is des
ktop app) so that the data (MSDE database) is on shared server. Are their any specific customizations that you are doing to the setup. Do you have any code for this which you can post for all...
Thanks a goodluck
dev
|||The number of connection that you can have with MSDE are the same as SQL
Server (32767) . The limits in MSDE are related to the amount of work that
it can do at any given time and the size of the database. If your clients
are not hammering the database server with constant requests then it is
certainly possible to scale to possibly hundreds of connections. For
information about how this workload governor works see this link:
http://msdn.microsoft.com/library/?u...asp?frame=true
Your application should only hit the database when it needs to and you
should strive to get all the data you need for a function of your
application in one request. Use stored procedures to handle the logic of
what data elements you need; rather than getting a piece of data returning
it to the application, deciding you need an additional pieces of data and
then fetching them repeatedly from the database.
We have customers using MSDE with our application and running many client
workstations with no problems. On the other hand, many of our customers
already have one or more installations of SQL Server on site which they
install our database to and are able to scale to dozens of workstations.
Jim
"Ray Lavelle" <bostonpartykid@.yahoo.com> wrote in message
news:d8653140.0404150745.2f9911ec@.posting.google.c om...
> I have a Windows application I have developed in VB using a MSDE
> database. I will be distributing this to clients, most of which will
> have only about 2-4 terminals, but there are many that will have 10-15
> terminals running my application. I am afraid of what the performance
> is going to be like with clients running a high number of terminals
> because of the limitations of MSDE. I looked into the price of the
> full version of SQL server for clients with a larger number of
> terminals but it would cost way to much so that simply is not an
> option for any of them.
> I have spoken to other companies who develop products like mine and
> they say they have clients running close to 30 terminals off of MSDE
> with no slow down. They say they have done this by using connection
> pooling. I have looked around on this issue and most people post
> articles on connection pooling and the MSDE workload governor but I
> have not seen any practical examples on specifically how to setup a
> client application to overcome the MSDE workload limit.
> As far as connection pooling is concerned, how exactly will this help
> in limiting the workload? Does anyone have an specific examples of
> how I would do this? I don't want to keep looking around and having
> to experiment around with things that may or may not work because I
> have no real way of testing this other than giving it to clients to
> test. I'd really like to see an actual example of how someone has
> done specifically what I'm doing here and has gotten it to work. I'm
> surprised there are not more articles on this specific subject, but I
> could not find any.
> Any help would be appreciated, thanks...
|||Jim,
Just curious, how do you change the connection string to specify where the database as some of your clients use MSDE and some use SQL Server.. does it happen during the installation. Also do you prompt them during installation on whether they want to ins
tall MSDE or use SQL Server they already have...
thanks
dev
|||You'd be much better off just disabling the workload governor. It's really
easy to do, all you need is change one byte in a hex editor.
Here's the method:
1. The file you will be changing is SQLBOOT.DLL. This can be found in
Microsoft SQL Server\MSSQL\Binn. The rest of this method only applies to
version 2000.080.0194.00 of the file, as included in Service Pack 3a.
Check the version of the file by looking at the Version tab of its
Properties window, and the size of the file, which should be 33,340 bytes.
You may also want to check the MD5 sum of the file, which is
175b236765fb446f46da5da635681ab8.
2. Obtain a suitable hex editor from somewhere. A fairly decent one that can
do the job is available here:
http://www.catch22.org.uk/software/hexedit.asp
3. Make a backup copy of SQLBOOT.DLL somewhere, just in case.
4. Stop MSDE's MSSQLSERVER service.
5. Open the original SQLBOOT.DLL in the hex editor.
6. Find the byte at location 10145 decimal / 0x27A1 hexadecimal.
7. The current value of the byte should be 08. Change it to 00.
This changes the target benchmark users / concurrent workload limit value
from eight to zero. When the SQL Server reads this as being zero, it
disables the workload governor.
8. Save SQLBOOT.DLL.
9. Start the MSSQLSERVER service.
If it worked, the SQL statement "DBCC CONCURRENCYVIOLATION" should return
without any output (normally it would display a summary of when the workload
governor has been active.)
Hope this helps!

Overcoming MSDE Setup Problems

Here is my experience with installing MSDE.

I'm leaning C# and ASP.NET at the same time using the book "Microsoft ASP.NET Programming with Microsoft Visual C# .NET Step by Step". In Appendix C, P 577, it says to locate setup.exe under ��Microsoft Visual Studio .NET\Setup\MSDE and "run setup.exe to install MSDE."

This was my first mistake, because there are more recent versions available with security patches (for the slammer virus). I have been unable to successfully update the old version. The install program for MSDE has got to be a hackers delight because only a hacker can make it work. I decided to uninstall the old version of MSDE 2000 and install the latest download from the MSDN website. The new version would get most of the files installed and then rollback the install, removing all the files. When I tried to reinstall the old version, it did the same thing. At least the new version requires a password parameter for the sa user. The bad news is that the new password is ignored. Since I already installed the first version with a blank sa password by running setup.exe with no parameters the password will remain blank until I change it using the user friendly osql command line utility. More about osql later��

Here is how I solved the rollback problem:

I first (after many hours trying to modify the registry to clean up the mess Windows uninstaller left there) used the command line switch /L*V <your logfile name> to get a verbose log file. I noticed a property listed called "Disablerollback" this was set to 0. So, I ran setup on the command line as below (all one line):

>setup DisableRollback=1 /L*V "C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\setupbat.log" SAPWD="ignored password"

The setup still failed, but its tracks were preserved for XP to complain about on system restart.
I then restarted the system and logged in. XP threw an error dialog box with the message "Your server installation is either corrupt or has been tampered with (unknown package ID)��" I clicked OK and waited a few extra minutes for XP to finish logging me in.

After logging in, I closed the Service Manger from the taskbar notification area. I then deleted the folders 80, and MSSQL (name of default instance) from the target install directory. Finally, I ran setup.exe again as shown:

>setup /L*V "C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\setupgood.log" SAPWD="ignored password"

This time, after restarting, my old MSDE worked. This approach seems to only work with the first old version of MSDE that was shipped with Visual Studio .NET. I still have yet to figure out how to upgrade and get MSDE to work again.

Once you get MSDE to work, here are some tips on how to administer it using the osql command tool.
To change the sa password do the following (use null for a blank password):
>osql -U sa
Password:
1> sp-password @.old=null, @.new='newpassword', @.loginame='sa'
2> go
Password has been changed
3> quit

On page 113 of the authors' first attempt with the book "Microsoft ASP.NET Programming��", the hacks wrote:
Set up the SQL Server session state database by running the InstallSQLState.sql batch (located in ��) against the SQL Server you plan to use. (For more information about running batch statements, check with your database administrator or the SQL Server Books Online.)

Here is how to do it with osql:

> osql -S MSSQLSERVER -U sa -i InstallSQLState.sql

For less characters than it took to write the last parenthetical sentence, they could have just given the same example I supplied here.

If you want a graphical interface to administer you MSDE server, try downloading the small package for "Microsoft SQL Web Data Administrator" from Microsoft's website. This even comes with a modern installer. Here are some tips on how to connect to your locally installed MSDE using this utility:

The main dialog just requires that you click the start button. A login page comes up. To log in as sa, do the following:

? Click the "SQL Login" radio button.
? Under "Please enter a SQL Server name:" fill in the following text boxes:
? Username: sa
? Password: [your password | leave blank if no password is set]
? Server: (local)

This should get you to the server tools page. Click "Security", then Logins. Now, on the Logins page, you can add new users. If you install MSDE for mixed mode, you can add "Windows Integrated" user accounts. This best since you won't have to put passwords in your code to allow database access to these users. To add a user, click on "Create New Login". Set Authentication Method to "Windows Integrated" in the combo box. For Login Name you need to use the form <computername>\<username> . For example, "MSSQLServer\Dan".

If you did like I did, and installed MSDE in SQL login mode only, you can do the following registry hack to change it to mixed authentication mode:

1. Locate either of the following subkeys (depending on whether you installed MSDE as the default MSDE instance or as a named instance:
HKEY_LOCAL_MACHINE\Software\Microsoft\MSSqlserver\MSSqlServer

-or-

HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\<Instance Name>\MSSQLServer\

2. In the right-pane, double-click the LoginMode subkey.

3. In the DWORD Editor dialog box, set the value of this subkey to 1. Make sure that the Hex option is selected, and then click OK.

4. Restart the MSSQLSERVER and the SQLSERVERAgent services for this change to take effect.

Try this link for more details:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q322336Correction to this step:
3. In the DWORD Editor dialog box, set the value of this subkey to 1.

For Mixed mode, the subkey should be 0 or 2.
For Windows Integrated only, the subkey should be 1.|||First a syntax typo correction:
change sp-password to sp_password. So the section on changing the sa password should read:

To change the sa password do the following (use null for a blank password):
>osql -U sa
Password:
1> sp_password @.old=null, @.new='newpassword', @.loginame='sa'
2> go
Password has been changed
3> quit

Notes on upgrading to SP3a.

Prerequisites:
1) You have to know the sa password for this solution to work.
2) Parameters in example assume you are in mixed authentication mode.
3) You should stop SNMP services.

Command line setup:
At the command line, type the following or paste this in a *.bat file and run the bat file:

>setup /upgradesp sqlrun DISABLENETWORKPROTOCOLS=1 /L*V C:\sql2ksp3\MSDE\setupbat.log SAPWD=yourSApassword

The "DISABLENETWORKPROTOCOLS=1" is optional. The default when installing a new instance of SP3a is to disable network protocol support. I don't know what the option does when you are simply upgrading. You can run svrnetcn.exe from the Tools\Binn directory to enable network protocols later. I found this tip on another forum: http://www.mcse.ms/message290056.html

You need to check the log file (setupbat.log in this case) to make sure the upgrade finished successfully. It should say, "Configuration completed successfully."

I tried running this without the SAPWD parameter since this was left off the example under section 3.7.4 of the sp3readme.htm file. The upgrade failed. If the sa password is still blank it says to use the BLANKSAPWD=1 parameter. Requiring the password makes sense because the installer needs to access your database files in order to upgrade. The "Northwind" sample database was deleted during the upgrade.|||Ok I've got as far as this line:

>setup /L*V "C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\setupgood.log" SAPWD="ignored password"

When I restarted my computer I got the "Your server installation is either corrupt or has been tampered with..." message and the MSDE icon was in my System Tray (with a red square in a white circle). So I closed this program and entered the above code in cmd line. However a dialog box appeared and said it could not locate the above file. I tried looking in the directory specified above and I couldn't find the file or the folders "80" and "MSSQL" either.|||Hello!

I got the same problem when installing MSDE at the end the performance counters install fails, beauce it can not update the reg key (as mentioned in my therad).

To uninstall MSDE see 320873 (german). Tipp you need only the msizap.exe prog. Evt. you dont must donload the whole SDK.
But uninstalling and new installation doesnt help either.

There is still the problem with the performance counters, and there is no solution yet (I really looked the www for the last days and did not found any solution.

lg ifoko|||You need to open a cmd window and run the command from the path where "setup" for MSDE lives. "MSSQL" may be named something else if you used INSTANCE= <name> in your first install. The default install target path is "C:\Program Files\Microsoft SQL Server\". This is where you should find the "80" and "MSSQL" folder to delete. Use a search to locate the "80" folder if you have to.

The other path (C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\) is where my Microsoft Visual Studio .NET 2002 is installed. The buggy version of MSDE came with my .NET software.|||To VilleValo:

On second thought, I don't see how you could get "setup DisableRollback=1 /L*V "C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\setupbat.log" SAPWD=IgnoredPassword" to work, and you can't get "setup /L*V "C:\Program Files\Microsoft Visual Studio .NET\Setup\MSDE\setupgood.log" SAPWD=IgnoredPassword" to work. I created these commands in .bat files and ran the .bat files. This way, if I needed to make any further modifications, I could edit the .bat files. It also leaves a record of what I did.|||thx dran001 for help.

But my problem is that I got no previous "working" installation of MSDE.

The problem is that I cant update the Perflib\009 key. Either the registry is damaged, or some service lock the key.
And I still no found any help with issue.

lg|||I think my problem was caused by the setup.ini file that came shipped with .NET. This file contains:
[Options]
INSTANCENAME=VSdotNET

So when I did the first install, my instance of MSDE was named VSdotNET. When I tried to install SP3a version after the uninstall, I didn't use the ini file. I ran this install from a different folder. The Windows uninstall must have left references to VSdotNET in the registry which left me unable to install another instance since I had uninstalled the first instance. The default instance is just MSSQL. If you supply an INSTANCENAME option, the instance is named MSSQL$<instancename> or MSSQL$VSdotNET for example.

I think the PerfMon is loaded after the error so that the MSDE installer can draw a nice reverse progress bar as the install is being rolled back. Here is a clip of my log file were I think the real error is:

MSI (s) (7C:DC) [15:59:17:020]: QueryPathOfRegTypeLib returned -2147319779 in local context.Path is ''
MSI (s) (7C:DC) [15:59:17:020]: CMsiServices::ProcessTypeLibrary runs in local context, not impersonated.
MSI (s) (7C:DC) [15:59:17:120]: ProcessTypeLibraryCore returns: 0. (0 means OK)
MSI (s) (7C:DC) [15:59:17:120]: Executing op: TypeLibraryRegister(,,FilePath=C:\Program Files\Microsoft SQL Server\80\Tools\Binn\dtspkg.DLL,LibID={10010001-EB1C-11CF-AE6E-00AA004A34D5},Version=-2147483648,,Language=0,,BinaryType=0,IgnoreRegistrationFailure=0)
MSI (s) (7C:DC) [15:59:17:120]: QueryPathOfRegTypeLib returned -2147319779 in local context.Path is ''
MSI (s) (7C:DC) [15:59:17:120]: CMsiServices::ProcessTypeLibrary runs in local context, not impersonated.
MSI (s) (7C:DC) [15:59:17:181]: ProcessTypeLibraryCore returns: 0. (0 means OK)
MSI (s) (7C:DC) [15:59:17:181]: Executing op: TypeLibraryRegister(,,FilePath=C:\Program Files\Microsoft SQL Server\80\Tools\Binn\dtspump.DLL,LibID={10010200-740B-11D0-AE7B-00AA004A34D5},Version=-2147483648,,Language=0,,BinaryType=0,IgnoreRegistrationFailure=0)
MSI (s) (7C:DC) [15:59:17:181]: QueryPathOfRegTypeLib returned -2147319779 in local context.Path is ''
MSI (s) (7C:DC) [15:59:17:181]: CMsiServices::ProcessTypeLibrary runs in local context, not impersonated.
MSI (s) (7C:DC) [15:59:17:211]: ProcessTypeLibraryCore returns: 0. (0 means OK)
MSI (s) (7C:DC) [15:59:17:211]: Executing op: TypeLibraryRegister(,,FilePath=C:\WINDOWS\system32\atl.dll,LibID={44EC0535-400F-11D0-9DCD-00A0C90391D3},Version=-2147483648,,Language=0,,BinaryType=0,IgnoreRegistrationFailure=1)
MSI (s) (7C:DC) [15:59:17:221]: QueryPathOfRegTypeLib returned -2147319779 in local context.Path is ''
MSI (s) (7C:DC) [15:59:17:221]: CMsiServices::ProcessTypeLibrary runs in local context, not impersonated.
MSI (s) (7C:DC) [15:59:17:261]: ProcessTypeLibraryCore returns: 0. (0 means OK)
MSI (s) (7C:DC) [15:59:17:261]: Executing op: ActionStart(Name=InstallServices,Description=Installing new services,Template=Service: [2])
MSI (s) (7C:DC) [15:59:17:261]: Executing op: ProgressTotal(Total=2,Type=1,ByteEquivalent=1300000)
MSI (s) (7C:DC) [15:59:17:261]: Executing op: ServiceInstall(Name=SQLAgent$VSdotNET,DisplayName=SQLAgent$VSdotNET,ImagePath=C:\Program Files\Microsoft SQL Server\MSSQL$VSdotNET\Binn\sqlagent.EXE -i VSdotNET,ServiceType=16,StartType=3,ErrorControl=1,,Dependencies=MSSQL$VSdotNET
MSI (s) (7C:DC) [15:59:17:871]: Executing op: ServiceInstall(Name=MSSQL$VSdotNET,DisplayName=MSSQL$VSdotNET,ImagePath=C:\Program Files\Microsoft SQL Server\MSSQL$VSdotNET\Binn\sqlservr.exe -sVSdotNET,ServiceType=16,StartType=2,ErrorControl=1,,,,,,)
MSI (s) (7C:DC) [15:59:18:072]: Executing op: ActionStart(Name=InstallPerfMon.2D02443E_7002_4C0B_ABC9_EAB2C064397B,,)
MSI (s) (7C:DC) [15:59:18:082]: Executing op: CustomActionSchedule(Action=InstallPerfMon.2D02443E_7002_4C0B_ABC9_EAB2C064397B,ActionType=1025,Source=BinaryData,Target=InstallPerfMon,)
MSI (s) (7C:48) [15:59:18:152]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI8F.tmp, Entrypoint: InstallPerfMon