A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Word » Mailmerge
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Mail Merge to SQL Server without using an external ODC



 
 
Thread Tools Display Modes
  #11  
Old February 6th, 2007, 10:28 PM posted to microsoft.public.word.mailmerge.fields
Todd K.
external usenet poster
 
Posts: 48
Default Mail Merge to SQL Server without using an external ODC

Peter -

How do I set up the data source under c:mysource.odc instead of under "c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL tables, and
that worked great from my computer but not from anyone else's.


If you did this using a .odc, then you would have to distribute the .odc to
the other systems, and the other users would obviously have to have the
necessary permissions for the tables/views they need to access. You would
probably also have to re-issue the OpenDataSource call, for exampel in an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if you are
using SQL Server 2005 and the new drivers/providers that come with it. I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and specify
any query information in the SQLStatement and SQLStatement1 parameters in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b) is likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that OpenDataSource
call and specify where that empty .odc is. I suppose there are two possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc , for
everyone. can't do much harm - it's just an empty file and all the necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server database,
"mydb" is the name of the database you want to access and "mytable" is the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed to be
upgraded and changed from the current Access DB that we decided to build a
SQL Server project from scratch. Right now it is on my CPU as a MySQL
project, but upon completion we will move it to a separate server. The
Word
documents were rebuilt as Merge documents "linked" to the SQL tables, and
that worked great from my computer but not from anyone else's. So I
figured
how to use the code below on the current Access database allowing everyone
to
utilize them from their computers. When I essentially just changed the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data (i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean that the
underlying data moved to SQL Server (and that you still have linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take you a
step
further. As a rule, an OLE DB connection is advisable, and essential if
your
SQl Server database has Unicode fields in it (which it almost certainly
will
have if it was created from an Access project using the Upsizing wizard.

Connecting to SQL Server tables and views should be straightforward,
security issues permitting, but connecting to stored procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the source is
an
Access table (see below), but when the source changed to SQL Server it
quit
working. Is there a different protocol for SQL Server or is it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an external
object of some kind and don't allow DSN-less and ODC-less connections,
unless of course they were
a. worried that the end result would be loads of .doc files with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's wouldn't be
an
issue anyway)
or
b. worried that then people would be able to distibute their merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection information
right
into a Word document?

Which version of Word are we discussing? And do your systems have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires an
external
*.odc file. ODBC can probably do it. And a macro that links the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when they
designed
the interface) would be to distribute the *.odc file for the
connection
to everyone's "My Data Source" folder.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17
2005)
http://www.word.mvps.org

Word 2003, and all Microsoft systems have the SQL ODBC driver
installed.

The distribution path you describe would require an installer, which
is
a heck of a lot of trouble to get a 25-character connection string
down
to the users' machines. Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

g.










  #12  
Old February 6th, 2007, 10:49 PM posted to microsoft.public.word.mailmerge.fields
Peter Jamieson
external usenet poster
 
Posts: 4,550
Default Mail Merge to SQL Server without using an external ODC

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar, better
just to keep asking the questions and bear in mind that we're all working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL tables,
and
that worked great from my computer but not from anyone else's.


If you did this using a .odc, then you would have to distribute the .odc
to
the other systems, and the other users would obviously have to have the
necessary permissions for the tables/views they need to access. You would
probably also have to re-issue the OpenDataSource call, for exampel in an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if you are
using SQL Server 2005 and the new drivers/providers that come with it. I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1 parameters in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b) is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc , for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable" is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed to be
upgraded and changed from the current Access DB that we decided to
build a
SQL Server project from scratch. Right now it is on my CPU as a MySQL
project, but upon completion we will move it to a separate server. The
Word
documents were rebuilt as Merge documents "linked" to the SQL tables,
and
that worked great from my computer but not from anyone else's. So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just changed the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data (i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean that
the
underlying data moved to SQL Server (and that you still have linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take you a
step
further. As a rule, an OLE DB connection is advisable, and essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be straightforward,
security issues permitting, but connecting to stored procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the source
is
an
Access table (see below), but when the source changed to SQL Server
it
quit
working. Is there a different protocol for SQL Server or is it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection
information
right
into a Word document?

Which version of Word are we discussing? And do your systems
have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires an
external
*.odc file. ODBC can probably do it. And a macro that links the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when they
designed
the interface) would be to distribute the *.odc file for the
connection
to everyone's "My Data Source" folder.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17
2005)
http://www.word.mvps.org

Word 2003, and all Microsoft systems have the SQL ODBC driver
installed.

The distribution path you describe would require an installer,
which
is
a heck of a lot of trouble to get a 25-character connection
string
down
to the users' machines. Honestly, I think this is another of
those
situations where Microsoft didn't have *anything* in mind.

g.












  #13  
Old February 7th, 2007, 05:59 PM posted to microsoft.public.word.mailmerge.fields
Todd K.
external usenet poster
 
Posts: 48
Default Mail Merge to SQL Server without using an external ODC

Success! I set up a datasource just to the SQL Server and copied the .odc
file to a folder on my c: drive called "c:\DataSources)" and then placed the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource once, I
should be able to use code in the Word documents to draw from any table/view
in the database from anybody's computer (with proper permissions of course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar, better
just to keep asking the questions and bear in mind that we're all working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute the .odc
to
the other systems, and the other users would obviously have to have the
necessary permissions for the tables/views they need to access. You would
probably also have to re-issue the OpenDataSource call, for exampel in an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if you are
using SQL Server 2005 and the new drivers/providers that come with it. I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1 parameters in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b) is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc , for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable" is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed to be
upgraded and changed from the current Access DB that we decided to
build a
SQL Server project from scratch. Right now it is on my CPU as a MySQL
project, but upon completion we will move it to a separate server. The
Word
documents were rebuilt as Merge documents "linked" to the SQL tables,
and
that worked great from my computer but not from anyone else's. So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just changed the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data (i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean that
the
underlying data moved to SQL Server (and that you still have linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take you a
step
further. As a rule, an OLE DB connection is advisable, and essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be straightforward,
security issues permitting, but connecting to stored procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the source
is
an
Access table (see below), but when the source changed to SQL Server
it
quit
working. Is there a different protocol for SQL Server or is it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection
information
right
into a Word document?

Which version of Word are we discussing? And do your systems
have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires an
external
*.odc file. ODBC can probably do it. And a macro that links the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when they
designed
the interface) would be to distribute the *.odc file for the
connection
to everyone's "My Data Source" folder.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17
2005)
http://www.word.mvps.org

Word 2003, and all Microsoft systems have the SQL ODBC driver
installed.

The distribution path you describe would require an installer,
which
is
a heck of a lot of trouble to get a 25-character connection
string
down
to the users' machines. Honestly, I think this is another of
those
situations where Microsoft didn't have *anything* in mind.

g.













  #14  
Old February 7th, 2007, 06:19 PM posted to microsoft.public.word.mailmerge.fields
Peter Jamieson
external usenet poster
 
Posts: 4,550
Default Mail Merge to SQL Server without using an external ODC

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied the .odc
file to a folder on my c: drive called "c:\DataSources)" and then placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource once, I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar, better
just to keep asking the questions and bear in mind that we're all working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute the
.odc
to
the other systems, and the other users would obviously have to have
the
necessary permissions for the tables/views they need to access. You
would
probably also have to re-issue the OpenDataSource call, for exampel in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if you
are
using SQL Server 2005 and the new drivers/providers that come with it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1 parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b) is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc , for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable" is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed to
be
upgraded and changed from the current Access DB that we decided to
build a
SQL Server project from scratch. Right now it is on my CPU as a
MySQL
project, but upon completion we will move it to a separate server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's. So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean that
the
underlying data moved to SQL Server (and that you still have linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the
source
is
an
Access table (see below), but when the source changed to SQL
Server
it
quit
working. Is there a different protocol for SQL Server or is it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files
with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's
wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their
merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection
information
right
into a Word document?

Which version of Word are we discussing? And do your systems
have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires an
external
*.odc file. ODBC can probably do it. And a macro that links
the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when they
designed
the interface) would be to distribute the *.odc file for the
connection
to everyone's "My Data Source" folder.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun
17
2005)
http://www.word.mvps.org

Word 2003, and all Microsoft systems have the SQL ODBC driver
installed.

The distribution path you describe would require an installer,
which
is
a heck of a lot of trouble to get a 25-character connection
string
down
to the users' machines. Honestly, I think this is another of
those
situations where Microsoft didn't have *anything* in mind.

g.















  #15  
Old February 12th, 2007, 10:32 PM posted to microsoft.public.word.mailmerge.fields
Todd K.
external usenet poster
 
Posts: 48
Default Mail Merge to SQL Server without using an external ODC

I also noticed that if I put "Option Explicit" at the top of the code, I
don't get that warning "Do you want SQL to update..." I know that has been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied the .odc
file to a folder on my c: drive called "c:\DataSources)" and then placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource once, I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar, better
just to keep asking the questions and bear in mind that we're all working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute the
.odc
to
the other systems, and the other users would obviously have to have
the
necessary permissions for the tables/views they need to access. You
would
probably also have to re-issue the OpenDataSource call, for exampel in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if you
are
using SQL Server 2005 and the new drivers/providers that come with it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1 parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b) is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc , for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable" is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed to
be
upgraded and changed from the current Access DB that we decided to
build a
SQL Server project from scratch. Right now it is on my CPU as a
MySQL
project, but upon completion we will move it to a separate server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's. So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean that
the
underlying data moved to SQL Server (and that you still have linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the
source
is
an
Access table (see below), but when the source changed to SQL
Server
it
quit
working. Is there a different protocol for SQL Server or is it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files
with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's
wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their
merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection
information
right
into a Word document?

Which version of Word are we discussing? And do your systems
have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires an
external
*.odc file. ODBC can probably do it. And a macro that links
the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when they
designed
the interface) would be to distribute the *.odc file for the
connection
to everyone's "My Data Source" folder.

Cindy Meister

  #16  
Old February 12th, 2007, 10:43 PM posted to microsoft.public.word.mailmerge.fields
Peter Jamieson
external usenet poster
 
Posts: 4,550
Default Mail Merge to SQL Server without using an external ODC

That's also interesting - will take a look...

Peter Jamieson
"Todd K." wrote in message
...
I also noticed that if I put "Option Explicit" at the top of the code, I
don't get that warning "Do you want SQL to update..." I know that has
been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied the
.odc
file to a folder on my c: drive called "c:\DataSources)" and then
placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource once,
I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar,
better
just to keep asking the questions and bear in mind that we're all
working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of
under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute the
.odc
to
the other systems, and the other users would obviously have to have
the
necessary permissions for the tables/views they need to access. You
would
probably also have to re-issue the OpenDataSource call, for exampel
in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if
you
are
using SQL Server 2005 and the new drivers/providers that come with
it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1
parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b)
is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc ,
for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable"
is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed
to
be
upgraded and changed from the current Access DB that we decided
to
build a
SQL Server project from scratch. Right now it is on my CPU as a
MySQL
project, but upon completion we will move it to a separate
server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.
So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just
changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean
that
the
underlying data moved to SQL Server (and that you still have
linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take
you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the
source
is
an
Access table (see below), but when the source changed to SQL
Server
it
quit
working. Is there a different protocol for SQL Server or is
it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files
with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's
wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their
merge
qapplications reasonably easily :-)

Peter Jamieson

"Graham" wrote in message
oups.com...
Cindy M.
wrote:
Hi Graham,

Is there any way to embed the SQL Server connection
information
right
into a Word document?

Which version of Word are we discussing? And do your
systems
have
an
ODBC
driver for SQL Server installed?

I think it can't be done for OLE DB, as this also requires
an
external
*.odc file. ODBC can probably do it. And a macro that
links
the
data
source when the file opens could probably work.

Another possibility (and it's what MSFT had in mind when
they
designed
the interface) would be to distribute the *.odc file for
the
connection
to everyone's "My Data Source" folder.

Cindy Meister



  #17  
Old February 15th, 2007, 05:58 PM posted to microsoft.public.word.mailmerge.fields
Todd K.
external usenet poster
 
Posts: 48
Default Mail Merge to SQL Server without using an external ODC

This is kind of bizarre, but I started having some of my documents give me
the "Do you want SQL to update..." message again. I discovered that if I set
up the mail merge first, then go back and paste the code in "on open", I
don't get the message. However, if I paste the code in first, then go back
and set up the merge, I get the message.

"Peter Jamieson" wrote:

That's also interesting - will take a look...

Peter Jamieson
"Todd K." wrote in message
...
I also noticed that if I put "Option Explicit" at the top of the code, I
don't get that warning "Do you want SQL to update..." I know that has
been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied the
.odc
file to a folder on my c: drive called "c:\DataSources)" and then
placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource once,
I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar,
better
just to keep asking the questions and bear in mind that we're all
working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of
under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute the
.odc
to
the other systems, and the other users would obviously have to have
the
necessary permissions for the tables/views they need to access. You
would
probably also have to re-issue the OpenDataSource call, for exampel
in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if
you
are
using SQL Server 2005 and the new drivers/providers that come with
it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to, and
specify
any query information in the SQLStatement and SQLStatement1
parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on (b)
is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder, build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc ,
for
everyone. can't do much harm - it's just an empty file and all the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl Server
database,
"mydb" is the name of the database you want to access and "mytable"
is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much needed
to
be
upgraded and changed from the current Access DB that we decided
to
build a
SQL Server project from scratch. Right now it is on my CPU as a
MySQL
project, but upon completion we will move it to a separate
server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.
So I
figured
how to use the code below on the current Access database allowing
everyone
to
utilize them from their computers. When I essentially just
changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you mean
that
the
underlying data moved to SQL Server (and that you still have
linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file) or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will take
you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when the
source
is
an
Access table (see below), but when the source changed to SQL
Server
it
quit
working. Is there a different protocol for SQL Server or is
it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in mind.

I certainly don't understand why they insist that you have an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc files
with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's
wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute their
merge
qapplications reasonably easily :-)

  #18  
Old February 15th, 2007, 07:55 PM posted to microsoft.public.word.mailmerge.fields
Peter Jamieson
external usenet poster
 
Posts: 4,550
Default Mail Merge to SQL Server without using an external ODC

More weird Word MailMerge-related behaviour has been reported in the last
week or so in this group than I can remember for quite a while:-) For my
part, if a problem can be worked around, I try not to dwell on it, because
investigating problems (a) isn't my job and (b) usually involves intensive
effort. But I will try to have a look at this one as well...

When you say "on open", do you mean a Document_Open() sub in either the
document or its template, an AutoOpen, or something else?

Peter Jamieson
"Todd K." wrote in message
...
This is kind of bizarre, but I started having some of my documents give me
the "Do you want SQL to update..." message again. I discovered that if I
set
up the mail merge first, then go back and paste the code in "on open", I
don't get the message. However, if I paste the code in first, then go
back
and set up the merge, I get the message.

"Peter Jamieson" wrote:

That's also interesting - will take a look...

Peter Jamieson
"Todd K." wrote in message
...
I also noticed that if I put "Option Explicit" at the top of the code, I
don't get that warning "Do you want SQL to update..." I know that has
been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied
the
.odc
file to a folder on my c: drive called "c:\DataSources)" and then
placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource
once,
I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar,
better
just to keep asking the questions and bear in mind that we're all
working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of
under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute
the
.odc
to
the other systems, and the other users would obviously have to
have
the
necessary permissions for the tables/views they need to access.
You
would
probably also have to re-issue the OpenDataSource call, for
exampel
in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if
you
are
using SQL Server 2005 and the new drivers/providers that come
with
it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to,
and
specify
any query information in the SQLStatement and SQLStatement1
parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on
(b)
is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are
two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder,
build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc
,
for
everyone. can't do much harm - it's just an empty file and all
the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will
probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" &
_
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl
Server
database,
"mydb" is the name of the database you want to access and
"mytable"
is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's
native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much
needed
to
be
upgraded and changed from the current Access DB that we
decided
to
build a
SQL Server project from scratch. Right now it is on my CPU as
a
MySQL
project, but upon completion we will move it to a separate
server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.
So I
figured
how to use the code below on the current Access database
allowing
everyone
to
utilize them from their computers. When I essentially just
changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the
data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you
mean
that
the
underlying data moved to SQL Server (and that you still have
linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need
either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file)
or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will
take
you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the
Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when
the
source
is
an
Access table (see below), but when the source changed to
SQL
Server
it
quit
working. Is there a different protocol for SQL Server or
is
it
probably
in
the routing?:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="I:\Applications\Databases\ProjectOne.adp", _
LinkToSource:=True, _
Connection:="TABLE TblAmendment_Ren", _
SQLStatement:="SELECT * FROM [TblAmendment_Ren]"
Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

"Peter Jamieson" wrote:

Did you work out how to do the ODBC connection?

Honestly, I think this is another of those
situations where Microsoft didn't have *anything* in
mind.

I certainly don't understand why they insist that you have
an
external
object of some kind and don't allow DSN-less and ODC-less
connections,
unless of course they were
a. worried that the end result would be loads of .doc
files
with
embedded
plain text login/password info.
(but if you're using SQL Server integrated security that's
wouldn't
be
an
issue anyway)
or
b. worried that then people would be able to distibute
their
merge
qapplications reasonably easily :-)



  #19  
Old February 15th, 2007, 08:11 PM posted to microsoft.public.word.mailmerge.fields
Todd K.
external usenet poster
 
Posts: 48
Default Mail Merge to SQL Server without using an external ODC

Sorry, I meant in the Document_Open() sub of the Word document. I didn't
mean for you to do any heavy research or anything, I just know you answer a
lot of the issues in this group and I thought you might find it useful.

"Peter Jamieson" wrote:

More weird Word MailMerge-related behaviour has been reported in the last
week or so in this group than I can remember for quite a while:-) For my
part, if a problem can be worked around, I try not to dwell on it, because
investigating problems (a) isn't my job and (b) usually involves intensive
effort. But I will try to have a look at this one as well...

When you say "on open", do you mean a Document_Open() sub in either the
document or its template, an AutoOpen, or something else?

Peter Jamieson
"Todd K." wrote in message
...
This is kind of bizarre, but I started having some of my documents give me
the "Do you want SQL to update..." message again. I discovered that if I
set
up the mail merge first, then go back and paste the code in "on open", I
don't get the message. However, if I paste the code in first, then go
back
and set up the merge, I get the message.

"Peter Jamieson" wrote:

That's also interesting - will take a look...

Peter Jamieson
"Todd K." wrote in message
...
I also noticed that if I put "Option Explicit" at the top of the code, I
don't get that warning "Do you want SQL to update..." I know that has
been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied
the
.odc
file to a folder on my c: drive called "c:\DataSources)" and then
placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource
once,
I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere (or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are unfamiliar,
better
just to keep asking the questions and bear in mind that we're all
working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead of
under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.

If you did this using a .odc, then you would have to distribute
the
.odc
to
the other systems, and the other users would obviously have to
have
the
necessary permissions for the tables/views they need to access.
You
would
probably also have to re-issue the OpenDataSource call, for
exampel
in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security, you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all if
you
are
using SQL Server 2005 and the new drivers/providers that come
with
it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect to,
and
specify
any query information in the SQLStatement and SQLStatement1
parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file) and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on
(b)
is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there are
two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder,
build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g. c:\myodcs\empty.odc
,
for
everyone. can't do much harm - it's just an empty file and all
the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will
probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" &
_
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl
Server
database,
"mydb" is the name of the database you want to access and
"mytable"
is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's
native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much
needed
to
be
upgraded and changed from the current Access DB that we
decided
to
build a
SQL Server project from scratch. Right now it is on my CPU as
a
MySQL
project, but upon completion we will move it to a separate
server.
The
Word
documents were rebuilt as Merge documents "linked" to the SQL
tables,
and
that worked great from my computer but not from anyone else's.
So I
figured
how to use the code below on the current Access database
allowing
everyone
to
utilize them from their computers. When I essentially just
changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the
data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you
mean
that
the
underlying data moved to SQL Server (and that you still have
linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need
either
a. a suitable ODBC DSN (either "machine" DSN or .dsn file)
or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will
take
you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it almost
certainly
will
have if it was created from an Access project using the
Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when
the

  #20  
Old February 15th, 2007, 08:33 PM posted to microsoft.public.word.mailmerge.fields
Peter Jamieson
external usenet poster
 
Posts: 4,550
Default Mail Merge to SQL Server without using an external ODC

Sorry, I meant in the Document_Open() sub of the Word document.

OK.

I thought you might find it useful.


I certainly do. In some respects, the weirder, the better, precisely because
this is stuff I've never encountered myself. But there's a lot of ground to
cover...:-)

Peter Jamieson

"Todd K." wrote in message
...
Sorry, I meant in the Document_Open() sub of the Word document. I didn't
mean for you to do any heavy research or anything, I just know you answer
a
lot of the issues in this group and I thought you might find it useful.

"Peter Jamieson" wrote:

More weird Word MailMerge-related behaviour has been reported in the last
week or so in this group than I can remember for quite a while:-) For my
part, if a problem can be worked around, I try not to dwell on it,
because
investigating problems (a) isn't my job and (b) usually involves
intensive
effort. But I will try to have a look at this one as well...

When you say "on open", do you mean a Document_Open() sub in either the
document or its template, an AutoOpen, or something else?

Peter Jamieson
"Todd K." wrote in message
...
This is kind of bizarre, but I started having some of my documents give
me
the "Do you want SQL to update..." message again. I discovered that if
I
set
up the mail merge first, then go back and paste the code in "on open",
I
don't get the message. However, if I paste the code in first, then go
back
and set up the merge, I get the message.

"Peter Jamieson" wrote:

That's also interesting - will take a look...

Peter Jamieson
"Todd K." wrote in message
...
I also noticed that if I put "Option Explicit" at the top of the
code, I
don't get that warning "Do you want SQL to update..." I know that
has
been a
problem for a lot of people using Merge documents...

"Peter Jamieson" wrote:

Good! Thanks for the feedback.

Peter Jamieson

"Todd K." wrote in message
...
Success! I set up a datasource just to the SQL Server and copied
the
.odc
file to a folder on my c: drive called "c:\DataSources)" and then
placed
the
following code in the Word Merge document:

Private Sub Document_Open()

Me.MailMerge.OpenDataSource _
Name:="c:\DataSources\GOLD-10455 ProjectONESQL.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Persist Security Info=False;Initial Catalog=ProjectOneSQL;data
source=GOLD-10455;", _
SQLStatement:="SELECT * FROM [TblRptCompletion]", _
subType:=wdMergeSubTypeOther

Me.MailMerge.Destination = wdSendToNewDocument
Me.MailMerge.Execute
Windows(Me).Close wdDoNotSaveChanges

End Sub

If I set up everybody's computer with this folder and datasource
once,
I
should be able to use code in the Word documents to draw from any
table/view
in the database from anybody's computer (with proper permissions
of
course).

THANKS!

"Peter Jamieson" wrote:

Set it up wherever you can, then copy it using Windows Exploere
(or
whatever). The .odc file is just a file.

If you're getting into areas of Windows etc. that are
unfamiliar,
better
just to keep asking the questions and bear in mind that we're
all
working
within a particular time zone...

Peter Jamieson


"Todd K." wrote in message
...
Peter -

How do I set up the data source under c:mysource.odc instead
of
under
"c:\my
documents\todd kirby..."? I can't seem to do it.

- Todd

"Peter Jamieson" wrote:

The Word
documents were rebuilt as Merge documents "linked" to the
SQL
tables,
and
that worked great from my computer but not from anyone
else's.

If you did this using a .odc, then you would have to
distribute
the
.odc
to
the other systems, and the other users would obviously have
to
have
the
necessary permissions for the tables/views they need to
access.
You
would
probably also have to re-issue the OpenDataSource call, for
exampel
in
an
AutoOpen macro.

If you're using SQl Server with Windows Integrated Security,
you
shouldn't
have too many problems in this area. If you're not, then
a. everything gets a lot more difficult, straight away
b. I'm not even sure you will be able to make it work at all
if
you
are
using SQL Server 2005 and the new drivers/providers that come
with
it.
I
haven't been able to do it with SQl Server security so far.

Also, you may need to consider

http://support.microsoft.com/kb/825765

However, when you use a .odc you currently have two choices:
a. have a .odc for each table or view you want to connect
to,
and
specify
any query information in the SQLStatement and SQLStatement1
parameters
in
Word's OpenDataSource method
b. use one completely empty .odc (i.e. an empty text file)
and
specify
everything you need in the OpenDataSource call.

It seems likely that distributing a set of solutions based on
(b)
is
likely
to be easier than basing them on (a).

Let's suppose you head for (b). You still have to write that
OpenDataSource
call and specify where that empty .odc is. I suppose there
are
two
possible
solutions:
a. put an empty .odc in every user's My Data Sources folder,
build
the
complete pathname for that file for each user and use that
b. use a completely standard pathname, e.g.
c:\myodcs\empty.odc
,
for
everyone. can't do much harm - it's just an empty file and
all
the
necessary
security is handled elsewhere. I hope.

As for the OpenDataSource code, with an empty.odc you will
probably
need
something like

ActiveDocument.MailMerge.OpenDataSource _
Name:="c:\myodcs\empty.odc", _
Connection:="Provider=SQLOLEDB.1;Integrated Security=SSPI;"
&
_
"Persist Security Info=False;Initial Catalog=mydb;Data
Source=myserver;"
_
SQLSatatement:="SELECT FROM ""mytable"", _
SubType:=wdMergeSubTypeOther

where "myserver" is the name of the server running your SQl
Server
database,
"mydb" is the name of the database you want to access and
"mytable"
is
the
table or view from which you want to retrieve data.

You'll need a different Provider name for SQl Server 2005's
native
provider...

See if that gets you any further.

Peter Jamieson

"Todd K." wrote in message
...
1) Word 2003
2) The whole thing will be moved to SQL Server. So much
needed
to
be
upgraded and changed from the current Access DB that we
decided
to
build a
SQL Server project from scratch. Right now it is on my CPU
as
a
MySQL
project, but upon completion we will move it to a separate
server.
The
Word
documents were rebuilt as Merge documents "linked" to the
SQL
tables,
and
that worked great from my computer but not from anyone
else's.
So I
figured
how to use the code below on the current Access database
allowing
everyone
to
utilize them from their computers. When I essentially just
changed
the
code
in the OpenDataSource, it can't seem to find the SQL table
3) I just want to connect to a SQL Server table, no stored
procedures.

"Peter Jamieson" wrote:

Which version of Word?

At the moment I'd guess your code is using DDE to get the
data
(i.e.
Access
will open and get the data).

When you say that the source changed to SQl Server do you
mean
that
the
underlying data moved to SQL Server (and that you still
have
linked
tables
in your .adp) or that the whole thing moved to SQL Server?

For starters, to connect directly to SQL Server you need
either
a. a suitable ODBC DSN (either "machine" DSN or .dsn
file)
or
b. a suitable OLE DB .udl file or
c. a suitable OLE DB .odc file

I can go into the details if necessary but maybe that will
take
you
a
step
further. As a rule, an OLE DB connection is advisable, and
essential
if
your
SQl Server database has Unicode fields in it (which it
almost
certainly
will
have if it was created from an Access project using the
Upsizing
wizard.

Connecting to SQL Server tables and views should be
straightforward,
security issues permitting, but connecting to stored
procedures/stored
functions is another matter.

Peter Jamieson

"Todd K." wrote in message
news Peter -

I have a similar situation. I have code that works when
the



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 12:12 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.