How to reset the autoincrement field in MS Access Table
Many times we use autoicrement field in Ms Access table and we have noticed that the value of autoincrement field keeps on increasing ever if we delete all the rows of the table and add new row.
In order to reset the autoincrement field value back to 1, do the following:
1. Delete all the rows from the table.
2. Compact the whole database .
This will automatically reset the autoincrement value back to 1.
Wednesday, December 23, 2009
Tuesday, December 22, 2009
Introducing WCF 3.5
This post is dedicated to WCF and its basics. We will go through various conceptual points of WCF and learn step by step implementation of WCF.
This post will cover few fundamental topics like:
• What is Windows Communication Foundation?
• Advantage of WCF
• What is an endpoint?
• Structure of endpoint or ABC of an end point.
• Explaining Address
• Explaining Binding and type of binding
• How to select proper binding
• Contracts and type of contracts
• Discussing Service Contract in detail।
What is WCF?
WCF stands for Windows Communication Foundation and comes along with Dot net framework 3.0 onwards and as a part of operating system from Vista onwards.
Business process in today’s market depends on various systems based on systems that runs on different platform within or outside an organization. There must be a way , a solution to have a communication between these various systems.
Why to use WCF?
WCF basically is a Microsoft’s solution to develop communication between distributed application। One may think why to use WCF when we already have lot of options to develop distributed application in past. The one line answer is that WCF acts as an unified technology that encapsulates all existing technologies to develop distributed application such as .NET Remoting, ASMX, MSMQ etc.
Apart from that we get lot of option on how to host the WCF service like IIS, or Widows Activated Service (WAS) etc. That we will discuss in later post.
I am eliminating discussion on history of distributed application since distributed application development is such a huge topic that it will divert our objective to learn WCF basics , However, throughout the document, I will map the similarity between existing distributed application solution to WCF।
Endpoint is the part that a service exposes to the outer system. It defines various details of a service hosted. The consumer reads the endpoint to judge the nature, type of the hosted service.
The ABC of WCF Endpoint:
Three basic component of any WCF service is :
“A” is for Address: Where to find the service
“B” is for Binding: How to communicate with the service
“C” is for Contract: What to send to the service or what to expect from the service.
Address:
It defines where on the network messages should be sent so that the endpoint receives them. This is the location to which messages must be sent by the client.
The address for an endpoint is a unique Uniform Resource Locator (URL) that identifies the location of the service. The address should follow the Web Service Addressing (WS-Addressing) standard, which means it might contain the following four parts:
• Scheme: The top-level portion of the address, this is typically “http” followed by a colon.
This is not the same thing as a protocol, even though it commonly uses the same letters as the protocol.
• Machine: Identifies the machine name, which can be a public URL or a local identifier.
• Port: The optional port number, preceded by a colon.
• Path: The path used to locate the service files. Typically, this is just the service name, but the path
Syntax of an address will be: Scheme://Machine[:Port]/Path1/Path2
Examples:
http://localhost:8080/Service1
http://localhost/Service1/SubService
http://www.ServiceHost.com/Service1
net.tcp://localhost:1234/OrderService
WCF supports several protocols, and each has its own particular addressing format.
1. HTTP protocol:
HTTP services can be either self-hosted or hosted on Internet Information Services (IIS). When addressing an HTTP service in a self-hosted scenario, you use the following format:
http://localhost:8080/QuickReturns/Exchange
2. TCP Protocol:
The TCP transport uses the net.tcp: scheme but otherwise follows the same rules as described
for HTTP addresses. Here is an example:
net.tcp://localhost:8080/QuickReturns/Exchange
3. MSMQ:
You can use the Microsoft Message Queue (MSMQ) transport in an asynchronous one-way
(fire-and-forget) or duplex type of messaging pattern and use the MSMQ features of Windows. net.msmq://localhost/private$/QuickReturnSettleTrade
4. Named Pipes:
It is a common way to provide a means to implement inter- or in-process communication.
The Named Pipes transport in WCF supports only local communication and uses the
net.pipes scheme. Port numbers don’t have any meaning with the Named Pipes transport.
This results in the following address format:
net।pipe://localhost/QuickReturns/Exchange
Binding:
A binding defines how you can communicate with the service. It is the primary extension point of the ABCs of WCF. The binding controls the following:
• The transport (HTTP, MSMQ, Named Pipes, TCP)
• The channels (one-way, duplex, request-reply)
• The encoding (XML, binary, MTOM…)
• The supported WS-* protocols (WS-Security, WS-Federation, WS-Reliability, WS-Transactions)
WCF provides a default set of bindings that should cover most of your requirements. If the default bindings don’t cover your requirements, you can build your own binding by extending from CustomBinding.
There are nine preconfigured bindings in WCF. Each of these provides the means for a particular distributed computing need. There are several factors that determine which binding to choose for a specific application, including security, interoperability, reliability, performance, and transaction requirements.
Table below compares the nine preconfigured bindings by showing the common features they support. This table can be used to select a best binding for a particular need.
Below is the process that will help you to select the binding you required for your application:
Contract:
A contract is a description of the messages that are passed to and from service endpoints.
There are three types of contracts in WCF:
• Service contracts : Service contracts describe the functional operations implemented by the service. A service contract maps the class methods of a .NET type to WSDL services, port types, and operations. Operation contracts within service contracts describe the service operations, which are the methods that implement functions of the service.
• Data contracts: Data contracts describe data structures that are used by the service to communicate with clients. A data contract maps CLR types to XML Schema Definitions (XSD) and defines how they are serialized and deserialized. Data contracts describe all the data that is sent to or from service operations.
• Message contracts: Message contracts map CLR types to SOAP messages and describe the format of the SOAP messages and affect the WSDL and XSD definitions of those messages. Message contracts provide precise control over the SOAP headers and bodies.
We will cover each type of binding and contract as we moves ahead with the implantation of WCF service. All theory will really make all of confuse so we need a bit of coding also..
Explaining Service Contract:
NOTE: before going into code, I would like to mention that all class, attributes specified to WCF comes from System.ServiceModel namespace. So import this namespace before going for coding.
A service contract is a collective mechanism by which a service capabilities and requirements are specified for its consumers.
Few points regarding Service Contract:
• A service contract can be applied to a normal dot net class or an interface.
• Service contract attribute is not inherited. That means if you are inheriting a class that has service contract attribute to it, you need to define the attribute to the derived class also. It will not get inherited automatically.
• Best practice is to use service contract attribute to interface.
• Always use namespace and Name parameter when defining a service contract attribute.
Sample Code:
An interface defined as a service contract without any parameter.
[ServiceContract()]
public interface ITaskManagerService
{ …. }
An interface defined as a service contract without any parameter.
[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{ …। }
Explaining Operation Conntract:
The OperationContractAttribute, also defined in the System.ServiceModel namespace, can be applied only to methods. It is used to declare the method as belonging to a Service contract.
[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{
[OperationContract(IsOneWay = true,name=”Operation1”)]
void ProcessInsertMessage(Message message);
}
So the above piece of code displays a interface defined as a service contract and its method as an operation contract।
In next article, I will discuss Message Exchange Pattern and two other contracts that is Data Contract and Message Contract.
This post will cover few fundamental topics like:
• What is Windows Communication Foundation?
• Advantage of WCF
• What is an endpoint?
• Structure of endpoint or ABC of an end point.
• Explaining Address
• Explaining Binding and type of binding
• How to select proper binding
• Contracts and type of contracts
• Discussing Service Contract in detail।
What is WCF?
WCF stands for Windows Communication Foundation and comes along with Dot net framework 3.0 onwards and as a part of operating system from Vista onwards.
Business process in today’s market depends on various systems based on systems that runs on different platform within or outside an organization. There must be a way , a solution to have a communication between these various systems.
Why to use WCF?
WCF basically is a Microsoft’s solution to develop communication between distributed application। One may think why to use WCF when we already have lot of options to develop distributed application in past. The one line answer is that WCF acts as an unified technology that encapsulates all existing technologies to develop distributed application such as .NET Remoting, ASMX, MSMQ etc.
Apart from that we get lot of option on how to host the WCF service like IIS, or Widows Activated Service (WAS) etc. That we will discuss in later post.
I am eliminating discussion on history of distributed application since distributed application development is such a huge topic that it will divert our objective to learn WCF basics , However, throughout the document, I will map the similarity between existing distributed application solution to WCF।
Endpoint is the part that a service exposes to the outer system. It defines various details of a service hosted. The consumer reads the endpoint to judge the nature, type of the hosted service.
The ABC of WCF Endpoint:
Three basic component of any WCF service is :
“A” is for Address: Where to find the service
“B” is for Binding: How to communicate with the service
“C” is for Contract: What to send to the service or what to expect from the service.
Address:
It defines where on the network messages should be sent so that the endpoint receives them. This is the location to which messages must be sent by the client.
The address for an endpoint is a unique Uniform Resource Locator (URL) that identifies the location of the service. The address should follow the Web Service Addressing (WS-Addressing) standard, which means it might contain the following four parts:
• Scheme: The top-level portion of the address, this is typically “http” followed by a colon.
This is not the same thing as a protocol, even though it commonly uses the same letters as the protocol.
• Machine: Identifies the machine name, which can be a public URL or a local identifier.
• Port: The optional port number, preceded by a colon.
• Path: The path used to locate the service files. Typically, this is just the service name, but the path
Syntax of an address will be: Scheme://Machine[:Port]/Path1/Path2
Examples:
http://localhost:8080/Service1
http://localhost/Service1/SubService
http://www.ServiceHost.com/Service1
net.tcp://localhost:1234/OrderService
WCF supports several protocols, and each has its own particular addressing format.
1. HTTP protocol:
HTTP services can be either self-hosted or hosted on Internet Information Services (IIS). When addressing an HTTP service in a self-hosted scenario, you use the following format:
http://localhost:8080/QuickReturns/Exchange
2. TCP Protocol:
The TCP transport uses the net.tcp: scheme but otherwise follows the same rules as described
for HTTP addresses. Here is an example:
net.tcp://localhost:8080/QuickReturns/Exchange
3. MSMQ:
You can use the Microsoft Message Queue (MSMQ) transport in an asynchronous one-way
(fire-and-forget) or duplex type of messaging pattern and use the MSMQ features of Windows. net.msmq://localhost/private$/QuickReturnSettleTrade
4. Named Pipes:
It is a common way to provide a means to implement inter- or in-process communication.
The Named Pipes transport in WCF supports only local communication and uses the
net.pipes scheme. Port numbers don’t have any meaning with the Named Pipes transport.
This results in the following address format:
net।pipe://localhost/QuickReturns/Exchange
Binding:
A binding defines how you can communicate with the service. It is the primary extension point of the ABCs of WCF. The binding controls the following:
• The transport (HTTP, MSMQ, Named Pipes, TCP)
• The channels (one-way, duplex, request-reply)
• The encoding (XML, binary, MTOM…)
• The supported WS-* protocols (WS-Security, WS-Federation, WS-Reliability, WS-Transactions)
WCF provides a default set of bindings that should cover most of your requirements. If the default bindings don’t cover your requirements, you can build your own binding by extending from CustomBinding.
There are nine preconfigured bindings in WCF. Each of these provides the means for a particular distributed computing need. There are several factors that determine which binding to choose for a specific application, including security, interoperability, reliability, performance, and transaction requirements.
Table below compares the nine preconfigured bindings by showing the common features they support. This table can be used to select a best binding for a particular need.
Below is the process that will help you to select the binding you required for your application:
Contract:
A contract is a description of the messages that are passed to and from service endpoints.
There are three types of contracts in WCF:
• Service contracts : Service contracts describe the functional operations implemented by the service. A service contract maps the class methods of a .NET type to WSDL services, port types, and operations. Operation contracts within service contracts describe the service operations, which are the methods that implement functions of the service.
• Data contracts: Data contracts describe data structures that are used by the service to communicate with clients. A data contract maps CLR types to XML Schema Definitions (XSD) and defines how they are serialized and deserialized. Data contracts describe all the data that is sent to or from service operations.
• Message contracts: Message contracts map CLR types to SOAP messages and describe the format of the SOAP messages and affect the WSDL and XSD definitions of those messages. Message contracts provide precise control over the SOAP headers and bodies.
We will cover each type of binding and contract as we moves ahead with the implantation of WCF service. All theory will really make all of confuse so we need a bit of coding also..
Explaining Service Contract:
NOTE: before going into code, I would like to mention that all class, attributes specified to WCF comes from System.ServiceModel namespace. So import this namespace before going for coding.
A service contract is a collective mechanism by which a service capabilities and requirements are specified for its consumers.
Few points regarding Service Contract:
• A service contract can be applied to a normal dot net class or an interface.
• Service contract attribute is not inherited. That means if you are inheriting a class that has service contract attribute to it, you need to define the attribute to the derived class also. It will not get inherited automatically.
• Best practice is to use service contract attribute to interface.
• Always use namespace and Name parameter when defining a service contract attribute.
Sample Code:
An interface defined as a service contract without any parameter.
[ServiceContract()]
public interface ITaskManagerService
{ …. }
An interface defined as a service contract without any parameter.
[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{ …। }
Explaining Operation Conntract:
The OperationContractAttribute, also defined in the System.ServiceModel namespace, can be applied only to methods. It is used to declare the method as belonging to a Service contract.
[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{
[OperationContract(IsOneWay = true,name=”Operation1”)]
void ProcessInsertMessage(Message message);
}
So the above piece of code displays a interface defined as a service contract and its method as an operation contract।
In next article, I will discuss Message Exchange Pattern and two other contracts that is Data Contract and Message Contract.
Wednesday, November 18, 2009
All about Global.asax
This file is used by the application to hold application-level events, objects, and variables — all of which are accessible application-wide. Active Server Pages developers had something similar with the Global.asa file.
Your ASP.NET applications can have only a single Global.asax file. This file supports a number of items.
When it is created, you are given the following template:
<%@ Application Language="VB" %>
<script runat="server">
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application startup
End Sub
Sub Application_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application shutdown
End Sub
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when an unhandled error occurs
End Sub
Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a new session is started
End Sub
Sub Session_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a session ends.
' Note: The Session_End event is raised only when the sessionstate mode
' is set to InProc in the Web.config file. If session mode is
' set to StateServer
' or SQLServer, the event is not raised.
End Sub
</script>
Just as you can work with page-level events in your .aspx pages, you can work with overall application
events from the Global.asax file.
In addition to the events listed in this code example, the following list
details some of the events you can structure inside this file:
- Application_Start: Called when the application receives its very first request. It is an ideal spot in your application to assign any application-level variables or state that must be maintained across all users.
- Session_Start: Similar to the Application_Start event except that this event is fired when an individual user accesses the application for the first time. For instance, the Application_Start event fires once when the first request comes in, which gets the application going, but the Session_Start is invoked for each end user who requests something from the application for the first time.
- Application_BeginRequest: Although it not listed in the preceding template provided by Visual Studio 2008, the Application_BeginRequest event is triggered before each and every request that comes its way. This means that when a request comes into the server, before this request is processed, the Application_BeginRequest is triggered and dealt with before any processing of the request occurs.
- Application_AuthenticateRequest: Triggered for each request and enables you to set up custom authentications for a request.
- Application_Error: Triggered when an error is thrown anywhere in the application by any user of the application. This is an ideal spot to provide application-wide error handling or an event recording the errors to the server’s event logs.
- Session_End: When running in InProc mode, this event is triggered when an end user leaves the application.
- Application_End: Triggered when the application comes to an end. This is an event that most ASP.NET developers won’t use that often because ASP.NET does such a good job of closing and cleaning up any objects that are left around.
In addition to the global application events that the Global.asax file provides access to, you can also use directives in this file as you can with other ASP.NET pages. The Global.asax file allows for the following directives:
- @Application
- @Assembly
- @Import
These directives perform in the same way when they are used with other ASP.NET page types.
Your ASP.NET applications can have only a single Global.asax file. This file supports a number of items.
When it is created, you are given the following template:
<%@ Application Language="VB" %>
<script runat="server">
Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application startup
End Sub
Sub Application_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application shutdown
End Sub
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when an unhandled error occurs
End Sub
Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a new session is started
End Sub
Sub Session_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a session ends.
' Note: The Session_End event is raised only when the sessionstate mode
' is set to InProc in the Web.config file. If session mode is
' set to StateServer
' or SQLServer, the event is not raised.
End Sub
</script>
Just as you can work with page-level events in your .aspx pages, you can work with overall application
events from the Global.asax file.
In addition to the events listed in this code example, the following list
details some of the events you can structure inside this file:
- Application_Start: Called when the application receives its very first request. It is an ideal spot in your application to assign any application-level variables or state that must be maintained across all users.
- Session_Start: Similar to the Application_Start event except that this event is fired when an individual user accesses the application for the first time. For instance, the Application_Start event fires once when the first request comes in, which gets the application going, but the Session_Start is invoked for each end user who requests something from the application for the first time.
- Application_BeginRequest: Although it not listed in the preceding template provided by Visual Studio 2008, the Application_BeginRequest event is triggered before each and every request that comes its way. This means that when a request comes into the server, before this request is processed, the Application_BeginRequest is triggered and dealt with before any processing of the request occurs.
- Application_AuthenticateRequest: Triggered for each request and enables you to set up custom authentications for a request.
- Application_Error: Triggered when an error is thrown anywhere in the application by any user of the application. This is an ideal spot to provide application-wide error handling or an event recording the errors to the server’s event logs.
- Session_End: When running in InProc mode, this event is triggered when an end user leaves the application.
- Application_End: Triggered when the application comes to an end. This is an event that most ASP.NET developers won’t use that often because ASP.NET does such a good job of closing and cleaning up any objects that are left around.
In addition to the global application events that the Global.asax file provides access to, you can also use directives in this file as you can with other ASP.NET pages. The Global.asax file allows for the following directives:
- @Application
- @Assembly
- @Import
These directives perform in the same way when they are used with other ASP.NET page types.
How to place two classes written in different languages in App_Code
What is App_Code ?
The \App_Code folder is meant to store your classes, .wsdl files, and typed datasets. Any of these items stored in this folder are then automatically available to all the pages within your solution.
Everything placed in the \App_Code folder is compiled into a single assembly. The class files placed within the \App_Code folder are not required to use a specific language. This means that even if all the pages of the solution are written in Visual Basic 2008, the class in the \App_Code folder of the solution can be built in C#.
Here is a small catch...
Because all the classes contained in this folder are built into a single assembly, you cannot have classes of different languages sitting in the root \App_Code folder, as in the following example:
\App_Code
Class1.cs
Class2.vb
Having two classes made up of different languages in the \App_Code folder causes an
error to be thrown. It is impossible for the assigned compiler to work with two different languages.
Therefore, in order to be able to work with multiple languages in your \App_Code folder, you must make some changes to the folder structure and to the web.config file.
The first step is to add two new subfolders to the \App_Code folder
— a \VB folder and a \CS folder.
This gives you the following folder structure:
\App_Code
\VB
\CS
This still will not correctly compile these class files into separate assemblies, at least not until you make some additions to the web.config file.
In the web.config file , change the <compilation>
node so that it is structured as following:
<compilation>
<codeSubDirectories>
<add directoryName="VB"></add>
<add directoryName="CS"></add>
</codeSubDirectories>
</compilation>
Now that this is in place in your web.config file, you can work with each of the classes in your ASP.NET pages. In addition, any C# class placed in the CS folder is now automatically compiled just like any of the classes placed in the VB folder.
NOTE: The name of sub directories are'VB' and 'CS' for this example. You can put any name you wish to.
The \App_Code folder is meant to store your classes, .wsdl files, and typed datasets. Any of these items stored in this folder are then automatically available to all the pages within your solution.
Everything placed in the \App_Code folder is compiled into a single assembly. The class files placed within the \App_Code folder are not required to use a specific language. This means that even if all the pages of the solution are written in Visual Basic 2008, the class in the \App_Code folder of the solution can be built in C#.
Here is a small catch...
Because all the classes contained in this folder are built into a single assembly, you cannot have classes of different languages sitting in the root \App_Code folder, as in the following example:
\App_Code
Class1.cs
Class2.vb
Having two classes made up of different languages in the \App_Code folder causes an
error to be thrown. It is impossible for the assigned compiler to work with two different languages.
Therefore, in order to be able to work with multiple languages in your \App_Code folder, you must make some changes to the folder structure and to the web.config file.
The first step is to add two new subfolders to the \App_Code folder
— a \VB folder and a \CS folder.
This gives you the following folder structure:
\App_Code
\VB
\CS
This still will not correctly compile these class files into separate assemblies, at least not until you make some additions to the web.config file.
In the web.config file , change the <compilation>
node so that it is structured as following:
<compilation>
<codeSubDirectories>
<add directoryName="VB"></add>
<add directoryName="CS"></add>
</codeSubDirectories>
</compilation>
Now that this is in place in your web.config file, you can work with each of the classes in your ASP.NET pages. In addition, any C# class placed in the CS folder is now automatically compiled just like any of the classes placed in the VB folder.
NOTE: The name of sub directories are'VB' and 'CS' for this example. You can put any name you wish to.
Tuesday, November 10, 2009
SharePoint Server 2010 Preliminary System Requirements
Sharepoint Server 2010 is on its way and it is high time to get ourself familiar with the system requirement of SharePoint Server 2010..
- SharePoint Server 2010 will be 64 bit only.
- SharePoint Server 2010 requires 64 bit Windows Server 2008 (R2)
- SharePoint Server 2010 requires 64 bit SQL Server 2005 or 2008
- SharePoint Server 2010 will support only IE7, IE8 and Firefox 3.x on Windows OS.
- IE6 will not be supported by SharePoint Server 2010
The reason SharePoint platform is upgrading to 64 bit is to utilize the full power of extra bits while using 64 bit bus.
SharePoint performance and scalability can benefit significantly from 64-bit SQL Server and the throughput increases are significant enough for us to make the difficult decision to only support SharePoint Server 2010 on 64-bit SQL Server 2005 or 2008. It has been our strong recommendation for some time that SharePoint Server 2007 customers take advantage of 64-bit SQL Server due to the inherent performance and scale benefits it can provide.
Look out for the space for more news on SharePoint Server 2010.....
Varun
Tuesday, September 8, 2009
How to disconnect a map drive using vbscript
In my previous post, I described how to connect to a network drive.
In this post, I will demonstrate how to disconnect from an existing connected network drive.
Suppose we have a drive Z: that is a network drive connected. Following is the code regarding how ti remove it.
Option Explicit
Dim WshNetwork, ShareName
Set WshNetwork = WScript.CreateObject("WScript.Network")
ShareName = "Z:"
WshNetwork.RemoveNetworkDrive ShareName, true, true
WScript.Quit
We are creating an object of WScript.Network and calling method RemoveNetworkDrive by passing the drive letter.
In this post, I will demonstrate how to disconnect from an existing connected network drive.
Suppose we have a drive Z: that is a network drive connected. Following is the code regarding how ti remove it.
Option Explicit
Dim WshNetwork, ShareName
Set WshNetwork = WScript.CreateObject("WScript.Network")
ShareName = "Z:"
WshNetwork.RemoveNetworkDrive ShareName, true, true
WScript.Quit
We are creating an object of WScript.Network and calling method RemoveNetworkDrive by passing the drive letter.
How to map network drive using VBScript
Some time it is required to map a network drive using vbscript.
Today I will demonstate how to connet and then disconnect from a network drive.
In order to connect to a network drive, we need following data/information:
1. HomeServer Location: Actual path of the drive. In our example it is
"\\125.99.218.158\Data"
2. Name of the drive you wish to give: Let us say Z:
3. UserId/Password using which we will connect the map drive. If userid is same as logged in user then it is not required.
We will create an object of WScript.Network and call its method MapNetworkDrive
Here is the code:
Option Explicit
Dim strUser, strPassword, strDriveLetter, strHomeServer, strProfile
Dim objNetwork
Set objNetwork = CreateObject("WScript.Network")
strDriveLetter = "Z:"
strHomeServer = "\\125.99.218.158\Data"
strProfile = "False" ' Mapping (not) stored in user Profile
strUser = "USERID"
strPassword = "PASSWORD"
objNetwork.MapNetworkDrive strDriveLetter,strHomeServer,strProfile,strUser,strPassword
WScript.Quit
So the above code is creating an object of Wscript.Network and calling method MapNetworkDrive by passwing parameters like drive letter, hom server, userid and password.
There is one more parameter that is strProfile. If set true, it will store the drive info in user profile and it will connect automatically next time when user logs in.
Today I will demonstate how to connet and then disconnect from a network drive.
In order to connect to a network drive, we need following data/information:
1. HomeServer Location: Actual path of the drive. In our example it is
"\\125.99.218.158\Data"
2. Name of the drive you wish to give: Let us say Z:
3. UserId/Password using which we will connect the map drive. If userid is same as logged in user then it is not required.
We will create an object of WScript.Network and call its method MapNetworkDrive
Here is the code:
Option Explicit
Dim strUser, strPassword, strDriveLetter, strHomeServer, strProfile
Dim objNetwork
Set objNetwork = CreateObject("WScript.Network")
strDriveLetter = "Z:"
strHomeServer = "\\125.99.218.158\Data"
strProfile = "False" ' Mapping (not) stored in user Profile
strUser = "USERID"
strPassword = "PASSWORD"
objNetwork.MapNetworkDrive strDriveLetter,strHomeServer,strProfile,strUser,strPassword
WScript.Quit
So the above code is creating an object of Wscript.Network and calling method MapNetworkDrive by passwing parameters like drive letter, hom server, userid and password.
There is one more parameter that is strProfile. If set true, it will store the drive info in user profile and it will connect automatically next time when user logs in.
Subscribe to:
Posts (Atom)