Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
Is there any way to embed the SQL Server connection information right
into a Word document? I'd like to be able to e-mail the document to others within the organization without having to navigate them through the process of creating a data source. (They all have access to the SQL server, of course.) Thanks, g. |
#2
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
Hi Graham,
Is there any way to embed the SQL Server connection information right into a Word document? I'd like to be able to e-mail the document to others within the organization without having to navigate them through the process of creating a data source. (They all have access to the SQL server, of course.) 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 This reply is posted in the Newsgroup; please post any follow question or reply in the newsgroup and not by e-mail :-) |
#3
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#4
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#5
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#6
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#7
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#8
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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. |
#9
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
I set up a datasource just to the SQL Database and tried adjusting the code
as follows and it still says it can't find the source: Private Sub Document_Open() Me.MailMerge.OpenDataSource _ Name:="GOLD-10455 ProjectONESQL.odc", _ Connection:="Provider = SQLOLEDB.1;Integrated Security=SSPI;" & _ "Persist Security Info=False;Initial Catalog=ProjectOne.adp;Data Source=QryVW_Amendment;", _ SQLStatement:="SELECT * FROM [QryVW_Amendment]", _ SubType:=wdMergeSubTypeOther Me.MailMerge.Destination = wdSendToNewDocument Me.MailMerge.Execute Windows(Me).Close wdDoNotSaveChanges End Sub "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. |
#10
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
When you're dealing with SQL Server,
a. there's a machine where the SQL Server instance is located. That machine has a name, e.g. "myserver" b. that server can have a number of databases or "catalogs", each of which has a name, e.g. "ProjectOne". They aren't /file names/ like "ProjectOne.adp". However, just because your Access project is called ProjectOne.adp does not mean that whoever has set up the back-end SQL Server database has called the database "ProjectOne" either. What is the server name? What is the database name? Peter Jamieson "Todd K." wrote in message ... I set up a datasource just to the SQL Database and tried adjusting the code as follows and it still says it can't find the source: Private Sub Document_Open() Me.MailMerge.OpenDataSource _ Name:="GOLD-10455 ProjectONESQL.odc", _ Connection:="Provider = SQLOLEDB.1;Integrated Security=SSPI;" & _ "Persist Security Info=False;Initial Catalog=ProjectOne.adp;Data Source=QryVW_Amendment;", _ SQLStatement:="SELECT * FROM [QryVW_Amendment]", _ SubType:=wdMergeSubTypeOther Me.MailMerge.Destination = wdSendToNewDocument Me.MailMerge.Execute Windows(Me).Close wdDoNotSaveChanges End Sub "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. |
#11
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
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 |
#21
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
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:-) I wonder if this is related to recent security updates? I found I had to roll back to before the last batch to get an essential macro to run that grabbed data from Outlook. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org |
#22
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
Hi Graham,
Could well be. I wish it was easier to keep track of the impact of these changes! Peter Jamieson "Graham Mayor" wrote in message ... 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:-) I wonder if this is related to recent security updates? I found I had to roll back to before the last batch to get an essential macro to run that grabbed data from Outlook. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org |
#23
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail Merge to SQL Server without using an external ODC
Agreed - they tend to come thick and fast
-- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Peter Jamieson wrote: Hi Graham, Could well be. I wish it was easier to keep track of the impact of these changes! Peter Jamieson "Graham Mayor" wrote in message ... 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:-) I wonder if this is related to recent security updates? I found I had to roll back to before the last batch to get an essential macro to run that grabbed data from Outlook. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
How do I mail merge to EMAIL from MS Word AND add a pdf attachment | Mailmerge | |||
Heavy Mail Merge Application | Mailmerge | |||
mail merge documents moved from one server to another server don't | Mailmerge | |||
Mail Merge - Parameter prompts twice... | Mailmerge | |||
The remote server machine does not exist or is unavailable on Mail Merge | Mailmerge |