Opening a microsoft application from a stored procedure

Is there a way to call/launch a word document from a stored procedure?
Thanks for any help.Technically, yes. But why would you want to do such a crazy thing?
If you decided that you'd rather continue drinking the happy juice, you coul
d
use the sp_OA functions to call out to a COM dll that opens the Word documen
t
and does who knows what with it. If you were really ambitious, you could wri
te
an extended stored procedure in C++ to do the same thing.
Thomas
"Munch" <Munch@.discussions.microsoft.com> wrote in message
news:94F4A9C2-5399-4F64-B2D0-6C654A2DCCF7@.microsoft.com...
> Is there a way to call/launch a word document from a stored procedure?
> Thanks for any help.|||Would it be better to insert the path of the documents /files into a table
and have them executed from the tables? Is this possible? I know we used t
o
house jpgs in a table and referenced different jpgs depending on the user an
d
preferences. Can we do this with word docs and other MS Applications?
Thanks
"Thomas" wrote:

> Technically, yes. But why would you want to do such a crazy thing?
> If you decided that you'd rather continue drinking the happy juice, you co
uld
> use the sp_OA functions to call out to a COM dll that opens the Word docum
ent
> and does who knows what with it. If you were really ambitious, you could w
rite
> an extended stored procedure in C++ to do the same thing.
>
> Thomas
>
> "Munch" <Munch@.discussions.microsoft.com> wrote in message
> news:94F4A9C2-5399-4F64-B2D0-6C654A2DCCF7@.microsoft.com...
>
>|||Yes you can store any type of document in the database by using image column
s. A
column of type image can store any type of binary in its raw format. So, jus
t as
JPEGs can be stored in the db, so can Word documents. However, *storing* Wor
d
documents in the database is a far cry from *launching* Word from SQL Server
.
Determining whether you should store the actual files in the database instea
d of
a path is a cost-benefit analysis. Storing the files in the database makes
things like replication a bit easier and provides some security advantages.
In
addition, it makes accessing the file a little simpler in that everything is
retrieved from the database. The downside is that it makes it difficult to e
dit
the files as you need to make a program to pull and push the file to the
database. In addition, it bloats the size of the database making database
backups take longer.
Storing the path to the files makes it possible to view and edit the files
directly. However, you have to ensure that the path in the database stays in
sync with the path and filename on the disk. Where the path solution gets re
ally
tricky is with multiple servers and multiple sites. If that is not a concern
,
the I'd go with the path solution. I would ensure that websites cannot acces
s
the files directly, but rather go through a proxy that sends the binary to t
he
website code. In this way, you shield the storage mechanism and location fro
m
the website adding security. In addition, it allows you to easily switch
solutions without having to change the website code.
HTH
Thomas
"Munch" <Munch@.discussions.microsoft.com> wrote in message
news:28ACA9AE-D640-449C-9257-6690BA761FAA@.microsoft.com...
> Would it be better to insert the path of the documents /files into a table
> and have them executed from the tables? Is this possible? I know we used
to
> house jpgs in a table and referenced different jpgs depending on the user
and
> preferences. Can we do this with word docs and other MS Applications?
> Thanks
> "Thomas" wrote:
>|||Thomas:
Thanks for the valuable info. I will look into these options.
"Thomas Coleman" wrote:

> Yes you can store any type of document in the database by using image colu
mns. A
> column of type image can store any type of binary in its raw format. So, j
ust as
> JPEGs can be stored in the db, so can Word documents. However, *storing* W
ord
> documents in the database is a far cry from *launching* Word from SQL Serv
er.
> Determining whether you should store the actual files in the database inst
ead of
> a path is a cost-benefit analysis. Storing the files in the database makes
> things like replication a bit easier and provides some security advantages
. In
> addition, it makes accessing the file a little simpler in that everything
is
> retrieved from the database. The downside is that it makes it difficult to
edit
> the files as you need to make a program to pull and push the file to the
> database. In addition, it bloats the size of the database making database
> backups take longer.
> Storing the path to the files makes it possible to view and edit the files
> directly. However, you have to ensure that the path in the database stays
in
> sync with the path and filename on the disk. Where the path solution gets
really
> tricky is with multiple servers and multiple sites. If that is not a conce
rn,
> the I'd go with the path solution. I would ensure that websites cannot acc
ess
> the files directly, but rather go through a proxy that sends the binary to
the
> website code. In this way, you shield the storage mechanism and location f
rom
> the website adding security. In addition, it allows you to easily switch
> solutions without having to change the website code.
>
> HTH
>
> Thomas
>
> "Munch" <Munch@.discussions.microsoft.com> wrote in message
> news:28ACA9AE-D640-449C-9257-6690BA761FAA@.microsoft.com...
>
>