I want the server side (sql and business logic) to know about one type. And
the client app(s) could derive there own types as needed but also store
their derivations so they can deserialize them. Is there a pattern for
this? What I am thinking now is simple example like:
public interface IVehicle
{
string Name
{
get;
set;
}
string Type
{
get;
set;
}
string Guid
{
get;
set;
}
public class Vehicle : IVehicle
{
private string name;
private string type;
private string data;
public string Name { get/set imp }
public string Type { get/set imp } // Derived type name. Used by
client to know how to deserilize Data.
public string Data { get/set imp} // Derived types xml.
}
So server knows about the Vehicle type and that is all. It can store three
columns: Name, Type, and Data.
If a client just wants to use Vehicle(s) then it is all set. However, it
may want to derive a Corvette or some other vehicle from base like so.
public class Corvette : IVehicle
{
private string name;
private string type;
private string data;
// Derived fields.
private string color;
public string Name { get/set imp }
public string Type { get/set imp }
public string Data { get/set imp}
public string Color { get/set imp}
public Corvette() { }
public Corvette(Vehicle vehicle) { //create a corvette from a vehicle. }
}
So I can get Vehicles from the server and create Corvettes on the client
side. However I need to store back a Corvette on the server, but the server
only knows about Vehicle type. So I am thinking serialize the Corvette type
into xml string, create a new Vehicle using same Name. Set vehicle.Type to
"Corvette" and store xml string in vehicle.Data. Now send the Vehicle type
to server for storage in SQL using the 3 columns in Vehicle. Now if the
client needs Corvette type, it gets the Vehicle, checks the Type and
deserializes the Data string into Corvette type and uses it. So that is the
round trip. Not pretty, but only way I can figure so far to do it. Any
ideas? TIA
William Stacey [MVP]
William Stacey [MVP]
There was an MSDN article written by Andrew Conrad that covers a scenario
very close to what you want to do. He uses an xml overflow column to store
the additional properties of the subclass.
"Death, Taxes, and Relational Databases, Part 1"
http://msdn.microsoft.com/library/de...ml04212003.asp
Specifically the section entitled: "Extending the Business Objects"
"William Stacey [MVP]" wrote:
> I want the server side (sql and business logic) to know about one type. And
> the client app(s) could derive there own types as needed but also store
> their derivations so they can deserialize them. Is there a pattern for
> this? What I am thinking now is simple example like:
> public interface IVehicle
> {
> string Name
> {
> get;
> set;
> }
> string Type
> {
> get;
> set;
> }
> string Guid
> {
> get;
> set;
> }
> public class Vehicle : IVehicle
> {
> private string name;
> private string type;
> private string data;
> public string Name { get/set imp }
> public string Type { get/set imp } // Derived type name. Used by
> client to know how to deserilize Data.
> public string Data { get/set imp} // Derived types xml.
> }
> So server knows about the Vehicle type and that is all. It can store three
> columns: Name, Type, and Data.
> If a client just wants to use Vehicle(s) then it is all set. However, it
> may want to derive a Corvette or some other vehicle from base like so.
> public class Corvette : IVehicle
> {
> private string name;
> private string type;
> private string data;
> // Derived fields.
> private string color;
> public string Name { get/set imp }
> public string Type { get/set imp }
> public string Data { get/set imp}
> public string Color { get/set imp}
> public Corvette() { }
> public Corvette(Vehicle vehicle) { //create a corvette from a vehicle. }
> }
> So I can get Vehicles from the server and create Corvettes on the client
> side. However I need to store back a Corvette on the server, but the server
> only knows about Vehicle type. So I am thinking serialize the Corvette type
> into xml string, create a new Vehicle using same Name. Set vehicle.Type to
> "Corvette" and store xml string in vehicle.Data. Now send the Vehicle type
> to server for storage in SQL using the 3 columns in Vehicle. Now if the
> client needs Corvette type, it gets the Vehicle, checks the Type and
> deserializes the Data string into Corvette type and uses it. So that is the
> round trip. Not pretty, but only way I can figure so far to do it. Any
> ideas? TIA
> --
> William Stacey [MVP]
> --
> William Stacey [MVP]
>
>
|||Thanks Todd. :-)
William Stacey [MVP]
"Todd Pfleiger [MSFT]" <ToddPfleigerMSFT@.discussions.microsoft.com> wrote in
message news:3B2852EA-495E-4D03-8CD7-10646EEF42E4@.microsoft.com...[vbcol=seagreen]
> There was an MSDN article written by Andrew Conrad that covers a scenario
> very close to what you want to do. He uses an xml overflow column to store
> the additional properties of the subclass.
> "Death, Taxes, and Relational Databases, Part 1"
> http://msdn.microsoft.com/library/de...ml04212003.asp
> Specifically the section entitled: "Extending the Business Objects"
>
> "William Stacey [MVP]" wrote:
Showing posts with label backend. Show all posts
Showing posts with label backend. Show all posts
Tuesday, March 27, 2012
Derived types and backend.
I want the server side (sql and business logic) to know about one type. And
the client app(s) could derive there own types as needed but also store
their derivations so they can deserialize them. Is there a pattern for
this? What I am thinking now is simple example like:
public interface IVehicle
{
string Name
{
get;
set;
}
string Type
{
get;
set;
}
string Guid
{
get;
set;
}
public class Vehicle : IVehicle
{
private string name;
private string type;
private string data;
public string Name { get/set imp }
public string Type { get/set imp } // Derived type name. Used by
client to know how to deserilize Data.
public string Data { get/set imp} // Derived types xml.
}
So server knows about the Vehicle type and that is all. It can store three
columns: Name, Type, and Data.
If a client just wants to use Vehicle(s) then it is all set. However, it
may want to derive a Corvette or some other vehicle from base like so.
public class Corvette : IVehicle
{
private string name;
private string type;
private string data;
// Derived fields.
private string color;
public string Name { get/set imp }
public string Type { get/set imp }
public string Data { get/set imp}
public string Color { get/set imp}
public Corvette() { }
public Corvette(Vehicle vehicle) { //create a corvette from a vehicle. }
}
So I can get Vehicles from the server and create Corvettes on the client
side. However I need to store back a Corvette on the server, but the server
only knows about Vehicle type. So I am thinking serialize the Corvette type
into xml string, create a new Vehicle using same Name. Set vehicle.Type to
"Corvette" and store xml string in vehicle.Data. Now send the Vehicle type
to server for storage in SQL using the 3 columns in Vehicle. Now if the
client needs Corvette type, it gets the Vehicle, checks the Type and
deserializes the Data string into Corvette type and uses it. So that is the
round trip. Not pretty, but only way I can figure so far to do it. Any
ideas? TIA
--
William Stacey [MVP]
William Stacey [MVP]There was an MSDN article written by Andrew Conrad that covers a scenario
very close to what you want to do. He uses an xml overflow column to store
the additional properties of the subclass.
"Death, Taxes, and Relational Databases, Part 1"
http://msdn.microsoft.com/library/d.../>
4212003.asp
Specifically the section entitled: "Extending the Business Objects"
"William Stacey [MVP]" wrote:
> I want the server side (sql and business logic) to know about one type. A
nd
> the client app(s) could derive there own types as needed but also store
> their derivations so they can deserialize them. Is there a pattern for
> this? What I am thinking now is simple example like:
> public interface IVehicle
> {
> string Name
> {
> get;
> set;
> }
> string Type
> {
> get;
> set;
> }
> string Guid
> {
> get;
> set;
> }
> public class Vehicle : IVehicle
> {
> private string name;
> private string type;
> private string data;
> public string Name { get/set imp }
> public string Type { get/set imp } // Derived type name. Used by
> client to know how to deserilize Data.
> public string Data { get/set imp} // Derived types xml.
> }
> So server knows about the Vehicle type and that is all. It can store thre
e
> columns: Name, Type, and Data.
> If a client just wants to use Vehicle(s) then it is all set. However, it
> may want to derive a Corvette or some other vehicle from base like so.
> public class Corvette : IVehicle
> {
> private string name;
> private string type;
> private string data;
> // Derived fields.
> private string color;
> public string Name { get/set imp }
> public string Type { get/set imp }
> public string Data { get/set imp}
> public string Color { get/set imp}
> public Corvette() { }
> public Corvette(Vehicle vehicle) { //create a corvette from a vehicle.
}
> }
> So I can get Vehicles from the server and create Corvettes on the client
> side. However I need to store back a Corvette on the server, but the serv
er
> only knows about Vehicle type. So I am thinking serialize the Corvette ty
pe
> into xml string, create a new Vehicle using same Name. Set vehicle.Type t
o
> "Corvette" and store xml string in vehicle.Data. Now send the Vehicle typ
e
> to server for storage in SQL using the 3 columns in Vehicle. Now if the
> client needs Corvette type, it gets the Vehicle, checks the Type and
> deserializes the Data string into Corvette type and uses it. So that is t
he
> round trip. Not pretty, but only way I can figure so far to do it. Any
> ideas? TIA
> --
> William Stacey [MVP]
> --
> William Stacey [MVP]
>
>|||Thanks Todd. :-)
William Stacey [MVP]
"Todd Pfleiger [MSFT]" <ToddPfleigerMSFT@.discussions.microsoft.com> wrote in
message news:3B2852EA-495E-4D03-8CD7-10646EEF42E4@.microsoft.com...
> There was an MSDN article written by Andrew Conrad that covers a scenario
> very close to what you want to do. He uses an xml overflow column to store
> the additional properties of the subclass.
> "Death, Taxes, and Relational Databases, Part 1"
> http://msdn.microsoft.com/library/d...
l04212003.asp
> Specifically the section entitled: "Extending the Business Objects"
>
> "William Stacey [MVP]" wrote:
>
the client app(s) could derive there own types as needed but also store
their derivations so they can deserialize them. Is there a pattern for
this? What I am thinking now is simple example like:
public interface IVehicle
{
string Name
{
get;
set;
}
string Type
{
get;
set;
}
string Guid
{
get;
set;
}
public class Vehicle : IVehicle
{
private string name;
private string type;
private string data;
public string Name { get/set imp }
public string Type { get/set imp } // Derived type name. Used by
client to know how to deserilize Data.
public string Data { get/set imp} // Derived types xml.
}
So server knows about the Vehicle type and that is all. It can store three
columns: Name, Type, and Data.
If a client just wants to use Vehicle(s) then it is all set. However, it
may want to derive a Corvette or some other vehicle from base like so.
public class Corvette : IVehicle
{
private string name;
private string type;
private string data;
// Derived fields.
private string color;
public string Name { get/set imp }
public string Type { get/set imp }
public string Data { get/set imp}
public string Color { get/set imp}
public Corvette() { }
public Corvette(Vehicle vehicle) { //create a corvette from a vehicle. }
}
So I can get Vehicles from the server and create Corvettes on the client
side. However I need to store back a Corvette on the server, but the server
only knows about Vehicle type. So I am thinking serialize the Corvette type
into xml string, create a new Vehicle using same Name. Set vehicle.Type to
"Corvette" and store xml string in vehicle.Data. Now send the Vehicle type
to server for storage in SQL using the 3 columns in Vehicle. Now if the
client needs Corvette type, it gets the Vehicle, checks the Type and
deserializes the Data string into Corvette type and uses it. So that is the
round trip. Not pretty, but only way I can figure so far to do it. Any
ideas? TIA
--
William Stacey [MVP]
William Stacey [MVP]There was an MSDN article written by Andrew Conrad that covers a scenario
very close to what you want to do. He uses an xml overflow column to store
the additional properties of the subclass.
"Death, Taxes, and Relational Databases, Part 1"
http://msdn.microsoft.com/library/d.../>
4212003.asp
Specifically the section entitled: "Extending the Business Objects"
"William Stacey [MVP]" wrote:
> I want the server side (sql and business logic) to know about one type. A
nd
> the client app(s) could derive there own types as needed but also store
> their derivations so they can deserialize them. Is there a pattern for
> this? What I am thinking now is simple example like:
> public interface IVehicle
> {
> string Name
> {
> get;
> set;
> }
> string Type
> {
> get;
> set;
> }
> string Guid
> {
> get;
> set;
> }
> public class Vehicle : IVehicle
> {
> private string name;
> private string type;
> private string data;
> public string Name { get/set imp }
> public string Type { get/set imp } // Derived type name. Used by
> client to know how to deserilize Data.
> public string Data { get/set imp} // Derived types xml.
> }
> So server knows about the Vehicle type and that is all. It can store thre
e
> columns: Name, Type, and Data.
> If a client just wants to use Vehicle(s) then it is all set. However, it
> may want to derive a Corvette or some other vehicle from base like so.
> public class Corvette : IVehicle
> {
> private string name;
> private string type;
> private string data;
> // Derived fields.
> private string color;
> public string Name { get/set imp }
> public string Type { get/set imp }
> public string Data { get/set imp}
> public string Color { get/set imp}
> public Corvette() { }
> public Corvette(Vehicle vehicle) { //create a corvette from a vehicle.
}
> }
> So I can get Vehicles from the server and create Corvettes on the client
> side. However I need to store back a Corvette on the server, but the serv
er
> only knows about Vehicle type. So I am thinking serialize the Corvette ty
pe
> into xml string, create a new Vehicle using same Name. Set vehicle.Type t
o
> "Corvette" and store xml string in vehicle.Data. Now send the Vehicle typ
e
> to server for storage in SQL using the 3 columns in Vehicle. Now if the
> client needs Corvette type, it gets the Vehicle, checks the Type and
> deserializes the Data string into Corvette type and uses it. So that is t
he
> round trip. Not pretty, but only way I can figure so far to do it. Any
> ideas? TIA
> --
> William Stacey [MVP]
> --
> William Stacey [MVP]
>
>|||Thanks Todd. :-)
William Stacey [MVP]
"Todd Pfleiger [MSFT]" <ToddPfleigerMSFT@.discussions.microsoft.com> wrote in
message news:3B2852EA-495E-4D03-8CD7-10646EEF42E4@.microsoft.com...
> There was an MSDN article written by Andrew Conrad that covers a scenario
> very close to what you want to do. He uses an xml overflow column to store
> the additional properties of the subclass.
> "Death, Taxes, and Relational Databases, Part 1"
> http://msdn.microsoft.com/library/d...
l04212003.asp
> Specifically the section entitled: "Extending the Business Objects"
>
> "William Stacey [MVP]" wrote:
>
Wednesday, March 21, 2012
Deployment for a small office
Hi,
I am creating a shrinkwrap winapp using vb.net which uses MSDE for backend. I have used the MSDE deployment toolkit to deploy MSDE along with the app. Everything works fine when the db and the app are on the same machine. I just install MSDE with named
instance for my company, create database and start the service. Even backup/restore work fine.
Now, my confusion is to how to make all this work for a small office where the setup will be like this (For e.g.):
1> 4 pcs (win xp) where my app will be installed to be used by 4 different users.
2> 1 central pc A (can be win xp) where the database is.
3> All 4 users want to share my database which is on the central pc A.
So, my concerns are:
1> How will the setup and deployment change.
2> Will the MSDE deployment toolkit still work.
3> Will I need to install myapp + MSDE on client's machine or just myapp.
4> What will I have to install on the central pc A.
5> Right now my connection string is like this:
data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser; Password=MyPassword
How will this change when the Db is on the central machine A.
6> If I use DMO, then what extra will I need to install on the 4 pcs and the central machine A.
Thanks
dev
hi dev_kh,
"dev_kh" <devkh@.discussions.microsoft.com> ha scritto nel messaggio
news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> ...
> So, my concerns are:
> 1> How will the setup and deployment change.
your setup shoul'd ask for MSDE installation, app installation or both...
you can even install MSDE on all client PCs, but they will not be used, or
shall not..
> 2> Will the MSDE deployment toolkit still work.
don't know.. never used :-(
> 3> Will I need to install myapp + MSDE on client's machine or just myapp.
see >1>
> 4> What will I have to install on the central pc A.
it depends... MSDE for sure, but il the server will actually works as a user
client too [as usal for small offices :-( ] you have to install your app
too..
> 5> Right now my connection string is like this:
> data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser;
>Password=MyPassword
> How will this change when the Db is on the central machine A.
data source=ServerComputerName\MyInstanceName;initial catalog=MyDB; User id
=MyUser; Password=MyPassword
> 6> If I use DMO, then what extra will I need to install on the 4 pcs and
the central machine A.
con the server PC you have to install nothing, as SQL-DMO is included in
MSDE package...
on all 4 client PCs, you have to install SQL-DMO component and
dependencies...
the complete dependency list is as above:
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\odbcbcp.dll; DestDir: WinSys ; sharedfile
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\sqlwoa.dll ; DestDir: WinSys
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\sqlwid.dll ; DestDir: WinSys
...\Programmi\Microsoft SQL Server\80\Tools\Binn\w95scm.dll; DestDir:
DestinationFolder\Binn
...\WINDOWS\SYSTEM\sqlunirl.dll ; DestDir: WinSys
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqlresld.dll; DestDir:
DestinationFolder\Binn
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqlsvc.dll; DestDir:
DestinationFolder\Binn
; not licensed by redist.txt but available after installation of MDAC2.6
...\Programmi\Microsoft SQL Server\80\Tools\Binn\Resources\1033\sqlsvc.RLL;
DestDir: DestinationFolder\Binn\Resources\1033
; not licensed by redist.txt but available after installation of MDAC2.6
...\Programmi\Microsoft SQL Server\80\Tools\Binn\Resources\1033\Sqldmo.rll;
DestDir: DestinationFolder\Binn\Resources\1033
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqldmo.dll; DestDir:
DestinationFolder\Binn ; file to be registered via regserver
DestinationFolder can either be the installation directory of one instance
of Microsoft SqlServer 2000, like ..\Program Files\Microsoft SQL
Server\80\Tools, even if no istance of SQL Server has been installed, or the
installation directory of your app. Please do respect the hierarchy
\Binn\Resources\1033 (where 1033 specifies the language), where needed, in
order to grant correct functionality of Ole-Automation objects.
In order to install SQL-DMO components for MSDE 2000, Microsoft Internet
Explorer 5.5 or higher is required.
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||See comments inline.
"dev_kh" <devkh@.discussions.microsoft.com> wrote in message
news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> Hi,
> I am creating a shrinkwrap winapp using vb.net which uses MSDE for
backend. I have used the MSDE deployment toolkit to deploy MSDE along with
the app. Everything works fine when the db and the app are on the same
machine. I just install MSDE with named instance for my company, create
database and start the service. Even backup/restore work fine.
> Now, my confusion is to how to make all this work for a small office where
the setup will be like this (For e.g.):
> 1> 4 pcs (win xp) where my app will be installed to be used by 4 different
users.
> 2> 1 central pc A (can be win xp) where the database is.
> 3> All 4 users want to share my database which is on the central pc A.
> So, my concerns are:
> 1> How will the setup and deployment change.
I'd prefer seperate installations of MSDE and app to put them in a single
setup procedure, unless the use who does the setup knows nothing but
double-clicking "setup.exe", since most likely, MSDE will be installed on
only one computer on the network while app will be installed on all
computers (of course it may also places on a network share and all computers
only get a shortcut to run it).
> 2> Will the MSDE deployment toolkit still work.
See above.
> 3> Will I need to install myapp + MSDE on client's machine or just myapp.
Install MSED on computer A only. as for app, you can choose install on all
client computers or place it on a sinle network share location. Now that it
is .NET app, of course yu have to make sure all computer has .NET framework
installed; amd also do some security configuration, since app loaded from
other computer is now allowed to run by default, you need to give it
permission to run: go to control panel->MS .NET framework confuguration to
allow the app loaed from other computer to run.
When I put my app in use, very often I know there are quite some bugs
undetected and some fixes are required soon or later, place the app in a
network share allows me just replace file(s) in a single location.
> 4> What will I have to install on the central pc A.
Nothing but MSDE.
> 5> Right now my connection string is like this:
> data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser;
Password=MyPassword
Just change "data source" to computer A's name: "data
source=computerAName\MSDEInstanceName;Initial..."
> How will this change when the Db is on the central machine A.
> 6> If I use DMO, then what extra will I need to install on the 4 pcs and
the central machine A.
You do not need install anything, unless your app uses DMO. DMO is installed
automatically with MSDE. Since MSDE is only installed on one computer, if
your app do require DMO to run, the get DMO on client computer without
install MSDE is quite tricky.
You probably use DMO for a few MSDE management task, like backup/restore.
I'd suggest you seperate this kind of task from your app into a single MSDE
app, which is only installed on the computer A. You do not want every user
to perform MSDE management task, do you?
> Thanks
> dev
|||Great,
So basically, in a small networked office setup I described,I will:
1> Install myapp on all 4 machines
2> Install MSDE on the centralserver A
3> Connection string will point to the machine A for datasource
But what about:
1> If I need to start the sqlserver service on clients machine, for e.g. to backup/restore database. How will I do it. Currently I use the following code to create the service controller and then start it if needed:
svc = New ServiceController("MSSQL$MyInstanceName)
What will I do when the service is on the central machine. How to start the service using the above code.
(See my clients will not have a dba and are assumed to not know that there is anything related to sql server on their machines, so we are providing the UI for backup/restore etc and the db functionality is kept as hidden as possible from them, this UI wil
l be in the tools on my vb.net app)
2> Will I need to run any network config utilities on the client machine. I know I will have to set disablenetworkprotocols to false on the server, but is there anything related to network access to be done on the client.
3> Andrea sometime back you mentioned something like, the location to backup should be from the MSDE machine's point of view.. so if PC1 wants to backup the db on it's D:\Backup drive, then what change will I have to do to this code below(which works fine
for a machine which has msde installed)
'--
cn = New SqlConnection(mMasterConnString)
cn.Open()
Dim cm As New SqlCommand
With cm
.Connection = cn
.CommandType = CommandType.Text
.CommandText = "BACKUP DATABASE " & mDBName & " TO DISK = '" & bkpFileWithPath & "' WITH NAME = My Backup', INIT"
.ExecuteNonQuery()
End With
'Note: bkpFileWithPath argument is: "D:\Backup\MyDB.bak"
'---
4> I guess I will take DMO slowly..
Thanks a lot guys. Hey Andrea do you have a blog?
dev_kh
"Norman Yuan" wrote:
> See comments inline.
> "dev_kh" <devkh@.discussions.microsoft.com> wrote in message
> news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> backend. I have used the MSDE deployment toolkit to deploy MSDE along with
> the app. Everything works fine when the db and the app are on the same
> machine. I just install MSDE with named instance for my company, create
> database and start the service. Even backup/restore work fine.
> the setup will be like this (For e.g.):
> users.
> I'd prefer seperate installations of MSDE and app to put them in a single
> setup procedure, unless the use who does the setup knows nothing but
> double-clicking "setup.exe", since most likely, MSDE will be installed on
> only one computer on the network while app will be installed on all
> computers (of course it may also places on a network share and all computers
> only get a shortcut to run it).
>
> See above.
>
> Install MSED on computer A only. as for app, you can choose install on all
> client computers or place it on a sinle network share location. Now that it
> is .NET app, of course yu have to make sure all computer has .NET framework
> installed; amd also do some security configuration, since app loaded from
> other computer is now allowed to run by default, you need to give it
> permission to run: go to control panel->MS .NET framework confuguration to
> allow the app loaed from other computer to run.
> When I put my app in use, very often I know there are quite some bugs
> undetected and some fixes are required soon or later, place the app in a
> network share allows me just replace file(s) in a single location.
>
> Nothing but MSDE.
> Password=MyPassword
> Just change "data source" to computer A's name: "data
> source=computerAName\MSDEInstanceName;Initial..."
> the central machine A.
> You do not need install anything, unless your app uses DMO. DMO is installed
> automatically with MSDE. Since MSDE is only installed on one computer, if
> your app do require DMO to run, the get DMO on client computer without
> install MSDE is quite tricky.
> You probably use DMO for a few MSDE management task, like backup/restore.
> I'd suggest you seperate this kind of task from your app into a single MSDE
> app, which is only installed on the computer A. You do not want every user
> to perform MSDE management task, do you?
>
>
>
I am creating a shrinkwrap winapp using vb.net which uses MSDE for backend. I have used the MSDE deployment toolkit to deploy MSDE along with the app. Everything works fine when the db and the app are on the same machine. I just install MSDE with named
instance for my company, create database and start the service. Even backup/restore work fine.
Now, my confusion is to how to make all this work for a small office where the setup will be like this (For e.g.):
1> 4 pcs (win xp) where my app will be installed to be used by 4 different users.
2> 1 central pc A (can be win xp) where the database is.
3> All 4 users want to share my database which is on the central pc A.
So, my concerns are:
1> How will the setup and deployment change.
2> Will the MSDE deployment toolkit still work.
3> Will I need to install myapp + MSDE on client's machine or just myapp.
4> What will I have to install on the central pc A.
5> Right now my connection string is like this:
data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser; Password=MyPassword
How will this change when the Db is on the central machine A.
6> If I use DMO, then what extra will I need to install on the 4 pcs and the central machine A.
Thanks
dev
hi dev_kh,
"dev_kh" <devkh@.discussions.microsoft.com> ha scritto nel messaggio
news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> ...
> So, my concerns are:
> 1> How will the setup and deployment change.
your setup shoul'd ask for MSDE installation, app installation or both...
you can even install MSDE on all client PCs, but they will not be used, or
shall not..
> 2> Will the MSDE deployment toolkit still work.
don't know.. never used :-(
> 3> Will I need to install myapp + MSDE on client's machine or just myapp.
see >1>
> 4> What will I have to install on the central pc A.
it depends... MSDE for sure, but il the server will actually works as a user
client too [as usal for small offices :-( ] you have to install your app
too..
> 5> Right now my connection string is like this:
> data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser;
>Password=MyPassword
> How will this change when the Db is on the central machine A.
data source=ServerComputerName\MyInstanceName;initial catalog=MyDB; User id
=MyUser; Password=MyPassword
> 6> If I use DMO, then what extra will I need to install on the 4 pcs and
the central machine A.
con the server PC you have to install nothing, as SQL-DMO is included in
MSDE package...
on all 4 client PCs, you have to install SQL-DMO component and
dependencies...
the complete dependency list is as above:
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\odbcbcp.dll; DestDir: WinSys ; sharedfile
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\sqlwoa.dll ; DestDir: WinSys
; not licensed by redist.txt but available after installation of MDAC2.6
...\WINDOWS\SYSTEM\sqlwid.dll ; DestDir: WinSys
...\Programmi\Microsoft SQL Server\80\Tools\Binn\w95scm.dll; DestDir:
DestinationFolder\Binn
...\WINDOWS\SYSTEM\sqlunirl.dll ; DestDir: WinSys
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqlresld.dll; DestDir:
DestinationFolder\Binn
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqlsvc.dll; DestDir:
DestinationFolder\Binn
; not licensed by redist.txt but available after installation of MDAC2.6
...\Programmi\Microsoft SQL Server\80\Tools\Binn\Resources\1033\sqlsvc.RLL;
DestDir: DestinationFolder\Binn\Resources\1033
; not licensed by redist.txt but available after installation of MDAC2.6
...\Programmi\Microsoft SQL Server\80\Tools\Binn\Resources\1033\Sqldmo.rll;
DestDir: DestinationFolder\Binn\Resources\1033
...\Programmi\Microsoft SQL Server\80\Tools\Binn\sqldmo.dll; DestDir:
DestinationFolder\Binn ; file to be registered via regserver
DestinationFolder can either be the installation directory of one instance
of Microsoft SqlServer 2000, like ..\Program Files\Microsoft SQL
Server\80\Tools, even if no istance of SQL Server has been installed, or the
installation directory of your app. Please do respect the hierarchy
\Binn\Resources\1033 (where 1033 specifies the language), where needed, in
order to grant correct functionality of Ole-Automation objects.
In order to install SQL-DMO components for MSDE 2000, Microsoft Internet
Explorer 5.5 or higher is required.
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||See comments inline.
"dev_kh" <devkh@.discussions.microsoft.com> wrote in message
news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> Hi,
> I am creating a shrinkwrap winapp using vb.net which uses MSDE for
backend. I have used the MSDE deployment toolkit to deploy MSDE along with
the app. Everything works fine when the db and the app are on the same
machine. I just install MSDE with named instance for my company, create
database and start the service. Even backup/restore work fine.
> Now, my confusion is to how to make all this work for a small office where
the setup will be like this (For e.g.):
> 1> 4 pcs (win xp) where my app will be installed to be used by 4 different
users.
> 2> 1 central pc A (can be win xp) where the database is.
> 3> All 4 users want to share my database which is on the central pc A.
> So, my concerns are:
> 1> How will the setup and deployment change.
I'd prefer seperate installations of MSDE and app to put them in a single
setup procedure, unless the use who does the setup knows nothing but
double-clicking "setup.exe", since most likely, MSDE will be installed on
only one computer on the network while app will be installed on all
computers (of course it may also places on a network share and all computers
only get a shortcut to run it).
> 2> Will the MSDE deployment toolkit still work.
See above.
> 3> Will I need to install myapp + MSDE on client's machine or just myapp.
Install MSED on computer A only. as for app, you can choose install on all
client computers or place it on a sinle network share location. Now that it
is .NET app, of course yu have to make sure all computer has .NET framework
installed; amd also do some security configuration, since app loaded from
other computer is now allowed to run by default, you need to give it
permission to run: go to control panel->MS .NET framework confuguration to
allow the app loaed from other computer to run.
When I put my app in use, very often I know there are quite some bugs
undetected and some fixes are required soon or later, place the app in a
network share allows me just replace file(s) in a single location.
> 4> What will I have to install on the central pc A.
Nothing but MSDE.
> 5> Right now my connection string is like this:
> data source=(local)\MyInstanceName;initial catalog=MyDB; User id =MyUser;
Password=MyPassword
Just change "data source" to computer A's name: "data
source=computerAName\MSDEInstanceName;Initial..."
> How will this change when the Db is on the central machine A.
> 6> If I use DMO, then what extra will I need to install on the 4 pcs and
the central machine A.
You do not need install anything, unless your app uses DMO. DMO is installed
automatically with MSDE. Since MSDE is only installed on one computer, if
your app do require DMO to run, the get DMO on client computer without
install MSDE is quite tricky.
You probably use DMO for a few MSDE management task, like backup/restore.
I'd suggest you seperate this kind of task from your app into a single MSDE
app, which is only installed on the computer A. You do not want every user
to perform MSDE management task, do you?
> Thanks
> dev
|||Great,
So basically, in a small networked office setup I described,I will:
1> Install myapp on all 4 machines
2> Install MSDE on the centralserver A
3> Connection string will point to the machine A for datasource
But what about:
1> If I need to start the sqlserver service on clients machine, for e.g. to backup/restore database. How will I do it. Currently I use the following code to create the service controller and then start it if needed:
svc = New ServiceController("MSSQL$MyInstanceName)
What will I do when the service is on the central machine. How to start the service using the above code.
(See my clients will not have a dba and are assumed to not know that there is anything related to sql server on their machines, so we are providing the UI for backup/restore etc and the db functionality is kept as hidden as possible from them, this UI wil
l be in the tools on my vb.net app)
2> Will I need to run any network config utilities on the client machine. I know I will have to set disablenetworkprotocols to false on the server, but is there anything related to network access to be done on the client.
3> Andrea sometime back you mentioned something like, the location to backup should be from the MSDE machine's point of view.. so if PC1 wants to backup the db on it's D:\Backup drive, then what change will I have to do to this code below(which works fine
for a machine which has msde installed)
'--
cn = New SqlConnection(mMasterConnString)
cn.Open()
Dim cm As New SqlCommand
With cm
.Connection = cn
.CommandType = CommandType.Text
.CommandText = "BACKUP DATABASE " & mDBName & " TO DISK = '" & bkpFileWithPath & "' WITH NAME = My Backup', INIT"
.ExecuteNonQuery()
End With
'Note: bkpFileWithPath argument is: "D:\Backup\MyDB.bak"
'---
4> I guess I will take DMO slowly..
Thanks a lot guys. Hey Andrea do you have a blog?
dev_kh
"Norman Yuan" wrote:
> See comments inline.
> "dev_kh" <devkh@.discussions.microsoft.com> wrote in message
> news:9D43D477-50C4-47DE-8174-CE196F5BD683@.microsoft.com...
> backend. I have used the MSDE deployment toolkit to deploy MSDE along with
> the app. Everything works fine when the db and the app are on the same
> machine. I just install MSDE with named instance for my company, create
> database and start the service. Even backup/restore work fine.
> the setup will be like this (For e.g.):
> users.
> I'd prefer seperate installations of MSDE and app to put them in a single
> setup procedure, unless the use who does the setup knows nothing but
> double-clicking "setup.exe", since most likely, MSDE will be installed on
> only one computer on the network while app will be installed on all
> computers (of course it may also places on a network share and all computers
> only get a shortcut to run it).
>
> See above.
>
> Install MSED on computer A only. as for app, you can choose install on all
> client computers or place it on a sinle network share location. Now that it
> is .NET app, of course yu have to make sure all computer has .NET framework
> installed; amd also do some security configuration, since app loaded from
> other computer is now allowed to run by default, you need to give it
> permission to run: go to control panel->MS .NET framework confuguration to
> allow the app loaed from other computer to run.
> When I put my app in use, very often I know there are quite some bugs
> undetected and some fixes are required soon or later, place the app in a
> network share allows me just replace file(s) in a single location.
>
> Nothing but MSDE.
> Password=MyPassword
> Just change "data source" to computer A's name: "data
> source=computerAName\MSDEInstanceName;Initial..."
> the central machine A.
> You do not need install anything, unless your app uses DMO. DMO is installed
> automatically with MSDE. Since MSDE is only installed on one computer, if
> your app do require DMO to run, the get DMO on client computer without
> install MSDE is quite tricky.
> You probably use DMO for a few MSDE management task, like backup/restore.
> I'd suggest you seperate this kind of task from your app into a single MSDE
> app, which is only installed on the computer A. You do not want every user
> to perform MSDE management task, do you?
>
>
>
Friday, March 9, 2012
Deploying database with .NET assemblies?
We're going to release a .NET 2.0 application soon (3-4 months) that uses SQL Express 2005 as the backend. We'd like to write some of our SPROC in C# (for obvious reasons!). Our .NET 2.0 app will be deployed using ClickOnce and each customer will have one instance of SQL 2005 Express installed locally.
Is there a way for be to deploy the database with all the C# SPROC "embedded" in it, or I'll have to register assemblies individually? I'm concerned about registering assemblies during installation, especially since we're deploying the application using ClickOnce (but not the database).
Also, from time to time, we need to add stored procedure or modify existing ones. In the "old" .NET 1.1 days, it was easy to do this. We had an assembly which main purpose was to update the database structure and SPROC with simple T-SQL commands (ie: ALTER PROCEDURE). Is there a way for us to achieve something similar with our application if we use C# SPROC?
Another concern I have is that the SQL database will most likely NOT be installed on the same machine as the client application (it will be installed on a server). Sending T-SQL queries worked fine with this scenario before, but now that things have changed, I'd like to know how to achieve such a thing.
Thanks for your help!
Carl
PS: any good book on Yukon out there yet? I can't find any!
Carl,
As a co-author of the book, I can definitely say it is interesting :-). Yes, it is based on a one year old beta, and much have changed. However, we do have an errata page as well as a page for changes, so you'll always be able to see the latest info.
ALTER will work remotely, BUT; notice that the SqlServer project (which are used to create assemblies for SQL Server) in Visual Studio does not have functionality for ALTER assembly. That's one of the reasons I created my "yukondeployment" MSBUILD tasks and templates for Visual Studio. You can download it and read more about it here.
Niels|||Thanks for your help! I will definately check out Yukon Deployment!
I didn't know you were co-author of the book. I thought you deserved one more sale so I went ahead and ordered the book. Hope it arrives in time for my vacation! I'll read it on the beach in a few days! I hope this sale will at least buy you a cold one.
Your help is appreciated!
Carl
Is there a way for be to deploy the database with all the C# SPROC "embedded" in it, or I'll have to register assemblies individually? I'm concerned about registering assemblies during installation, especially since we're deploying the application using ClickOnce (but not the database).
Also, from time to time, we need to add stored procedure or modify existing ones. In the "old" .NET 1.1 days, it was easy to do this. We had an assembly which main purpose was to update the database structure and SPROC with simple T-SQL commands (ie: ALTER PROCEDURE). Is there a way for us to achieve something similar with our application if we use C# SPROC?
Another concern I have is that the SQL database will most likely NOT be installed on the same machine as the client application (it will be installed on a server). Sending T-SQL queries worked fine with this scenario before, but now that things have changed, I'd like to know how to achieve such a thing.
Thanks for your help!
Carl
PS: any good book on Yukon out there yet? I can't find any!
Carl,
The best book out there on SQL Server 2005 is "A First Look at SQL Server 2005 for Developers" by Bob Beauchemin, Niels Berglund and Dan Sullivan.
To reload a new version of the assembly, using ALTER ASSEMBLY will work as long as the existing sprocs/functions have the same method signatures.
Deploying the database with the sprocs embedded is no problem. They are just held in varbinary form in a database level system table.
HTH,
Christian|||Christian,
Thanks for your answer! I looked into the Beauchemin's book on Amazon a few days ago and it looks interresting. What is holding me a little is that it's based on a 1 year old beta. Things have probably changed a lot since and might also change again for RTM.
About ALTER ASSEMBLY, do you know if it's possible to ADD managed procedures, functions or modify the signatures in some way? Also, do I need to use ALTER ASSEMBLY from the server machine or it could also work remotely? I assume it would, but I think I'm missing pieces of how this new managed SQL works right now...
Thanks a lot again!
Carl
|||
Carl Mercier wrote:
Christian,
Thanks for your answer! I looked into the Beauchemin's book on Amazon a few days ago and it looks interresting. What is holding me a little is that it's based on a 1 year old beta. Things have probably changed a lot since and might also change again for RTM.
As a co-author of the book, I can definitely say it is interesting :-). Yes, it is based on a one year old beta, and much have changed. However, we do have an errata page as well as a page for changes, so you'll always be able to see the latest info.
Sure you can add managed procedures, after running ALTER ASSEMBLY you just run CREATE FUNCTION/PROCEDURE/TRIGGER against your new methods. You are NOT allowed to modify signatures.
About ALTER ASSEMBLY, do you know if it's possible to ADD managed procedures, functions or modify the signatures in some way? Also, do I need to use ALTER ASSEMBLY from the server machine or it could also work remotely? I assume it would, but I think I'm missing pieces of how this new managed SQL works right now...
ALTER will work remotely, BUT; notice that the SqlServer project (which are used to create assemblies for SQL Server) in Visual Studio does not have functionality for ALTER assembly. That's one of the reasons I created my "yukondeployment" MSBUILD tasks and templates for Visual Studio. You can download it and read more about it here.
Niels|||Thanks for your help! I will definately check out Yukon Deployment!
I didn't know you were co-author of the book. I thought you deserved one more sale so I went ahead and ordered the book. Hope it arrives in time for my vacation! I'll read it on the beach in a few days! I hope this sale will at least buy you a cold one.
Your help is appreciated!
Carl
Sunday, February 19, 2012
Deploy database develop from MSDE
Hi,
I have a small access database develop using msde as back end. I want to put
this backend database on shared drive so that other user can access to it.
My question is
1 - Does I need to setup MSDE on every workstation?
2 - Can other user connect to this database using ODBC?
SF
Thank you very much for this useful tip.
SF
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:4s0fftFsu16iU1@.mid.individual.net...
> hi,
> SF wrote:
> SQL Server/MSDE is not a file based database like Access is... so you only
> have to put the database on the machine hosting the MSDE instance (and not
> on a shared folder).. obviously every machine in the lan can then access
> the MSDE service...
> ODBC api? yes, if you like the hard way, but you probably shoud consider
> other data acces methods, like ADO, Ado.Net and the like...
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz http://italy.mvps.org
> DbaMgr2k ver 0.20.0 - DbaMgr ver 0.64.0 and further SQL Tools
> -- remove DMO to reply
>
I have a small access database develop using msde as back end. I want to put
this backend database on shared drive so that other user can access to it.
My question is
1 - Does I need to setup MSDE on every workstation?
2 - Can other user connect to this database using ODBC?
SF
Thank you very much for this useful tip.
SF
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:4s0fftFsu16iU1@.mid.individual.net...
> hi,
> SF wrote:
> SQL Server/MSDE is not a file based database like Access is... so you only
> have to put the database on the machine hosting the MSDE instance (and not
> on a shared folder).. obviously every machine in the lan can then access
> the MSDE service...
> ODBC api? yes, if you like the hard way, but you probably shoud consider
> other data acces methods, like ADO, Ado.Net and the like...
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz http://italy.mvps.org
> DbaMgr2k ver 0.20.0 - DbaMgr ver 0.64.0 and further SQL Tools
> -- remove DMO to reply
>
Subscribe to:
Posts (Atom)