| Home |
| Search |
| Today's Posts |
|
#1
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
KB 825765 - just making sure...
Hi,
I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#2
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
I believe you have it covered. Either you get the warning or you eliminate
the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#3
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Thanks for the answer Graham... !
One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#4
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
If your mail merge main document has no data source attached when you open
it (manually or programmatically) and you then run a macro with an OpenDataSource call in it, does the document always end up attached to a data source, even if SQLSecuirtyCheck is absent or set to 1? If so, then if you (or your client) have control over the documents you are using as mail merge main documents, as long as they are always saved with no data source attached, you should be able to forget about SQLSecurityCheck. If there is no such control, you either need the SQLSecurityCheck entry set to 0 or a completely different approach to suppressing the message - it should in theory be possible to do it using the Windows API to detect the messages and send the correct Windows message to click the "Yes" button, cf. the Express ClickYes utility, which suppresses the dialog boxes that Outlook pops up when merging to e-mail (see http://www.contextmagic.com/express-clickyes/ ). If I were your client, I might regard that as an even greater risk, but I suppose it might at least offer a way to control which applications/documents worked and which did not. I make the above suggestion cautiously, because I have always found this particular problem and the registry fix a bit mystifying. The article only discusses opening documents that already have a connection, not situations where you issue an OpenDataSource during automation. But when people have had certain problems with programmatic connection and OpenDataSource appears to have failed silently, pointing them to the article usually appears to have done the trick. So some other factor appears to be involved, and I don't know exactly what. Peter Jamieson "Ulrika" wrote in message ... Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#5
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
So would it be possbile to attack the problem from that angle? Like
convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#6
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Whew, thanks Peter for all the suggestions, and with my limited Word
expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#7
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
I will think about this and be back, but just FYI: our data source is a
text file! That should simplify things, or..? Not really, because Word always uses an SQL SELECT statement even with text files. I just tried here and it looks as if a. if you connect using the Text converter, removing the RTF \mmquery field eliminates the prompt but causes causes Word to fail to find the source. b. if you connect using OLE DB, removing the \mmquery field works OK. However, since you usually see a prompt for a field delimiter character (comma/tab/other) whenever you open the .rtf file, you probably aren't using this method. NB this behaviour is fairly bizarre because it's clear from the ..rtf that Word stores the info. about which delimiter character it is using. (I haven't looked at the case where ODBC is used). If you don't know which you're using (it's not always obvious which Word uses), one difference is that the RTF for a text file connected via OLE DB has a {\mmodsotable filename#ext} field, and the RTF that uses the text converter does not. Also, when connecting in the first instance, the OLE DB connection pops up two dialog boxes asking for the field delimiter character. With the text converter, you see a box that asks for a field delimiter and a record delimiter. At the moment I don't know how Word decides which to use, but a. if the record delimiter is not carriage return/line feed (or something similar recognises by the OLEDB provider) Word cannot use OLE DB, as far as I know. The text converter lets you specify a number of other characters for that. b. recently I have found that using a SCHEMA.INI file to specify the delimiter character and sometimes other characteristics such as character set can make a significant difference in this area, even suppressing the prompt for a delimiter character. Previously I'd thought they were only used by the ODBC text driver. More on that if you need it. Sorry for the mass of acronyms and so on! Peter Jamieson "Ulrika" wrote in message ... Whew, thanks Peter for all the suggestions, and with my limited Word expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#8
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Thanks again - I still haven't had time to test anything, just glancing at
the discussion group now and then. But for when I have a chance to test: exactly how do i remove the \mmquery field? By "hacking" into the rtf file with like Notepad, or by some more sophisticated Word stuff? BTW FYI again, the programmatic mail merge is done via Progress 4gl, so no VB-stuff here... :-) /U "Peter Jamieson" wrote: I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? Not really, because Word always uses an SQL SELECT statement even with text files. I just tried here and it looks as if a. if you connect using the Text converter, removing the RTF \mmquery field eliminates the prompt but causes causes Word to fail to find the source. b. if you connect using OLE DB, removing the \mmquery field works OK. However, since you usually see a prompt for a field delimiter character (comma/tab/other) whenever you open the .rtf file, you probably aren't using this method. NB this behaviour is fairly bizarre because it's clear from the ..rtf that Word stores the info. about which delimiter character it is using. (I haven't looked at the case where ODBC is used). If you don't know which you're using (it's not always obvious which Word uses), one difference is that the RTF for a text file connected via OLE DB has a {\mmodsotable filename#ext} field, and the RTF that uses the text converter does not. Also, when connecting in the first instance, the OLE DB connection pops up two dialog boxes asking for the field delimiter character. With the text converter, you see a box that asks for a field delimiter and a record delimiter. At the moment I don't know how Word decides which to use, but a. if the record delimiter is not carriage return/line feed (or something similar recognises by the OLEDB provider) Word cannot use OLE DB, as far as I know. The text converter lets you specify a number of other characters for that. b. recently I have found that using a SCHEMA.INI file to specify the delimiter character and sometimes other characteristics such as character set can make a significant difference in this area, even suppressing the prompt for a delimiter character. Previously I'd thought they were only used by the ODBC text driver. More on that if you need it. Sorry for the mass of acronyms and so on! Peter Jamieson "Ulrika" wrote in message ... Whew, thanks Peter for all the suggestions, and with my limited Word expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#9
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Yes, you have to hack the RTF file directly. If you check Word
Tools|Options|General|Confirm conversions at open", when you open the .rtf you can open it as "Plain text" (you'll get a message that you can ignore when you save it). It's probably less confusing to use Notepad though. BTW I had a look at the OLE DB text thing and as far as I can tell, to avoid the delimiter dialog you do have to set up a SCHEMA.INI /and/ a .ODC file. So the wretched workaround ends up being quite complicated. We can go into the .odc stuff later. Peter Jamieson "Ulrika" wrote in message ... Thanks again - I still haven't had time to test anything, just glancing at the discussion group now and then. But for when I have a chance to test: exactly how do i remove the \mmquery field? By "hacking" into the rtf file with like Notepad, or by some more sophisticated Word stuff? BTW FYI again, the programmatic mail merge is done via Progress 4gl, so no VB-stuff here... :-) /U "Peter Jamieson" wrote: I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? Not really, because Word always uses an SQL SELECT statement even with text files. I just tried here and it looks as if a. if you connect using the Text converter, removing the RTF \mmquery field eliminates the prompt but causes causes Word to fail to find the source. b. if you connect using OLE DB, removing the \mmquery field works OK. However, since you usually see a prompt for a field delimiter character (comma/tab/other) whenever you open the .rtf file, you probably aren't using this method. NB this behaviour is fairly bizarre because it's clear from the ..rtf that Word stores the info. about which delimiter character it is using. (I haven't looked at the case where ODBC is used). If you don't know which you're using (it's not always obvious which Word uses), one difference is that the RTF for a text file connected via OLE DB has a {\mmodsotable filename#ext} field, and the RTF that uses the text converter does not. Also, when connecting in the first instance, the OLE DB connection pops up two dialog boxes asking for the field delimiter character. With the text converter, you see a box that asks for a field delimiter and a record delimiter. At the moment I don't know how Word decides which to use, but a. if the record delimiter is not carriage return/line feed (or something similar recognises by the OLEDB provider) Word cannot use OLE DB, as far as I know. The text converter lets you specify a number of other characters for that. b. recently I have found that using a SCHEMA.INI file to specify the delimiter character and sometimes other characteristics such as character set can make a significant difference in this area, even suppressing the prompt for a delimiter character. Previously I'd thought they were only used by the ODBC text driver. More on that if you need it. Sorry for the mass of acronyms and so on! Peter Jamieson "Ulrika" wrote in message ... Whew, thanks Peter for all the suggestions, and with my limited Word expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#10
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Hello again!
I have had time to try removing the \mmquery field, and it seems like i am using the "Text converter" since I get a message that word can not find the data source. So, is there a way around this, or should I forget that solution? Another yet untried solution is the one with a macro that does OpenDataSource. Primarily because I have no idea how to "disconnect" the data source from my document. Any hints? Hints on how to write the macro would also be welcome, I have found how to get to the editor (ALT-F8 etc) but I am not a VB programmer so it will take me a while to figure it out. As always, thanks in advance! "Peter Jamieson" wrote: Yes, you have to hack the RTF file directly. If you check Word Tools|Options|General|Confirm conversions at open", when you open the .rtf you can open it as "Plain text" (you'll get a message that you can ignore when you save it). It's probably less confusing to use Notepad though. BTW I had a look at the OLE DB text thing and as far as I can tell, to avoid the delimiter dialog you do have to set up a SCHEMA.INI /and/ a .ODC file. So the wretched workaround ends up being quite complicated. We can go into the .odc stuff later. Peter Jamieson "Ulrika" wrote in message ... Thanks again - I still haven't had time to test anything, just glancing at the discussion group now and then. But for when I have a chance to test: exactly how do i remove the \mmquery field? By "hacking" into the rtf file with like Notepad, or by some more sophisticated Word stuff? BTW FYI again, the programmatic mail merge is done via Progress 4gl, so no VB-stuff here... :-) /U "Peter Jamieson" wrote: I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? Not really, because Word always uses an SQL SELECT statement even with text files. I just tried here and it looks as if a. if you connect using the Text converter, removing the RTF \mmquery field eliminates the prompt but causes causes Word to fail to find the source. b. if you connect using OLE DB, removing the \mmquery field works OK. However, since you usually see a prompt for a field delimiter character (comma/tab/other) whenever you open the .rtf file, you probably aren't using this method. NB this behaviour is fairly bizarre because it's clear from the ..rtf that Word stores the info. about which delimiter character it is using. (I haven't looked at the case where ODBC is used). If you don't know which you're using (it's not always obvious which Word uses), one difference is that the RTF for a text file connected via OLE DB has a {\mmodsotable filename#ext} field, and the RTF that uses the text converter does not. Also, when connecting in the first instance, the OLE DB connection pops up two dialog boxes asking for the field delimiter character. With the text converter, you see a box that asks for a field delimiter and a record delimiter. At the moment I don't know how Word decides which to use, but a. if the record delimiter is not carriage return/line feed (or something similar recognises by the OLEDB provider) Word cannot use OLE DB, as far as I know. The text converter lets you specify a number of other characters for that. b. recently I have found that using a SCHEMA.INI file to specify the delimiter character and sometimes other characteristics such as character set can make a significant difference in this area, even suppressing the prompt for a delimiter character. Previously I'd thought they were only used by the ODBC text driver. More on that if you need it. Sorry for the mass of acronyms and so on! Peter Jamieson "Ulrika" wrote in message ... Whew, thanks Peter for all the suggestions, and with my limited Word expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#11
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Hi Ulrika,
So, is there a way around this, or should I forget that solution? There may be a way around it, but because you have to change the way Word connects to the text data and the other methods do not work the same way as the text converter a. it may turn out not to be possible b. even if it is possible, it will be more complicated because you will need at least one extra file and probably two, and you will have to patch the Windows Registry if you are using an extension other than a standard one such as .txt or .csv c. you may face limitations you would prefer to avoid. As far as I know, it is unlikely to be be possible if a. your text file does not have a record delimiter that the OLE DB provider recognises, i.e. if you are using anything other than CR, LF or a recognised combination, it probably won't work. b. your text file has more than around 255 fields There may of course be other reasons why it won't work :-( On the other hand, if it works, it could be the best way forward as no VBA would be needed. Let's create a really simple example to work with (NB I will be away for a while in about 5 days' time so if you need to come back for more assistance, before or after that, please...). I would also like to go through some stuff that doesn't quite do what you want so you can see the effect of each of the components in this approach. This message contains stage one of the example. If your real data files are simple and have the delimiters and character encoding the OLE DB provider expects, you may be able to apply the approach described here to your text files without anything further. Otherwise, I'll do a second message with the remaining stuff to do with SCHEMA.INI. Let's suppose you have a folder called c:\sample and a delimited file in it called c:\sample\mmds.txt, mmds standing for "mail merge data source") containing some simple multiline data as follows: k,name,address 1,A Baker,"23 High Street Atown Middleshire" 2,C Draper,"25 Finkle Street Btown Topshire" You should be able to set that up by a. creating c:\sample b. copying/pasting the above text into Notepad, making sure there are no blank lines after Topshire", then saving the file as c:\sample\mmds.txt Now open Word and a blank document. Although the following should work wherever you save it, let's call it c:\sample\mmmd.doc (i.e. mail merge main document). For the moment, check Word Tools|Options|General|"Confirm conversions at open". You can uncheck it later when you don't need it any more. Enable Word's mail merge toolbar (Tools|Customize). Because we're trying to ensure that the merge works without any special changes in the Windows Registry, delete the SQLSecurityCheck value or set it to 1. Click the second button (Select Data Source), navigate to c:\sample, select mmds.txt, and click Open. You should see a "Confirm Data Source" dialog box, which will probably display at least the following options, probably with "Text Files (*.txt)" highlighted. OLE DB Database Files Text Files (*.txt) Delimited Text Files via ODBC (*.txt, *.csv) If your display differs substantially, let me know. Select OLE DB Database Files and click OK. You should see another dialog box titled "Text File Connection Parameters". Select "Comma", and ensure "First row of data contains column headers" is checked. Click OK. For some reason, the dialog box is then redisplayed (on a fast system you may not even notice). The values will probably be as you just entered them. Otherwise, make sure they are correct and click OK again. Word should connect to the data source. You should be able to use the Insert Merge Fields button (6th on the Mail Merge Toolbar) to insert the fields k, name and address, and the preview button () to verify that the data is as you expect. Save the document and close it. Then reopen it. You will probably see... a. the SQL Security check prompt. Click Yes b. the "Text File Connection Parameters" dialog, probably with the wrong delimiter selected. Select comma and ensure "First row of data contains column headers" is checked. Click OK. This time you probably won't see the dialog again. Now copy/paste the following text into Notepad and save it in c:\sample\mmds.odc. The text begins with html and ends with /html, and contains some Javascript. That's because I've provided it exactly as it was created by Word and the Data Link Editor - in fact, you can remove an awful lot of this stuff and it will still work in Word. You may have to fix some of it up, particularly if you see highlighted links. Let me know if you have problems. html head meta http-equiv=Content-Type content="text/x-ms-odc; charset=utf-8" meta name=ProgId content=ODC.Table meta name=SourceType content=OLEDB meta name=Table content=mmds#txt xml id=docprops/xmlxml id=msodcodc:OfficeDataConnection xmlns  dc="urn:schemas-microsoft-comfficedc"xmlns="http://www.w3.org/TR/REC-html40" odc:Connection odc:Type="OLEDB" odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString odc:CommandTypeTable/odc:CommandType odc:CommandTextmmds#txt/odc:CommandText /odc:Connection /odc:OfficeDataConnection /xml style !-- .ODCDataSource { behavior: url(dataconn.htc); } -- /style /head body onload='init()' scroll=no leftmargin=0 topmargin=0 rightmargin=0 style='border: 0px' table style='border: solid 1px threedface; height: 100%; width: 100%' cellpadding=0 cellspacing=0 width='100%' tr td id=tdName style='font-family:arial; font-size:medium; padding: 3px; background-color: threedface' /td td id=tdTableDropdown style='padding: 3px; background-color: threedface; vertical-align: top; padding-bottom: 3px' /td /tr tr td id=tdDesc colspan='2' style='border-bottom: 1px threedshadow solid; font-family: Arial; font-size: 1pt; padding: 2px; background-color: threedface' /td /tr tr td colspan='2' style='height: 100%; padding-bottom: 4px; border-top: 1px threedhighlight solid;' div id='pt' style='height: 100%' class='ODCDataSource'/div /td /tr /table script language='javascript' function init() { var sName, sDescription; var i, j; try { sName = unescape(location.href) i = sName.lastIndexOf(".") if (i=0) { sName = sName.substring(1, i); } i = sName.lastIndexOf("/") if (i=0) { sName = sName.substring(i+1, sName.length); } document.title = sName; document.getElementById("tdName").innerText = sName; sDescription = document.getElementById("docprops").innerHTML; i = sDescription.indexOf("escription") if (i=0) { j = sDescription.indexOf("escription", i + 11); } if (i=0 && j = 0) { j = sDescription.lastIndexOf("/", j); if (j=0) { sDescription = sDescription.substring(i+11, j); if (sDescription != "") { document.getElementById("tdDesc").style.fontSize=" x-small"; document.getElementById("tdDesc").innerHTML = sDescription; } } } } catch(e) { } } /script /body /html ------------------------------------- Now, with your mmds.doc file open, Click the first button in the mailmerge toolbar (Main Document Setup) and select Normal Word Document. This removes the connection to the existing data source (and other info. such as sorts and filters, but not the Mail Merge fields). Click the second button (Select Data Source), locate the mmds.odc file you just saved, and open it. The "Confirm Data Source" dialog box should open, but this time there should be just one option, OLE DB Database Files Select that and click OK. You should not see the "Text File Connection Parameters" dialog box. Let me know if you do). You should be able to preview the data as before. Save and close mmmd.doc. Re-open it. You should see the SQL dialog. Click Yes. You should not see any other dialog boxes. Preview and check the data! Now save mmmd.doc as an rtf file, c:\sample\mmmd.rtf and close it. Re-open it as a text file using your preferred method, and locate and delete the \mmquery field, which should say {\mmquery SELECT * FROM `mmds#txt`} Make sure you don't delete anything else! Save and close the file. Now re-open the .rtf file in Word. You should see the Convert file dialog, and Rich text Format (RTF) should be displayed. If not, let me know, but try selecting the RTF option anyway and click OK. You should not see any other dialog, but the document should be connected to the data source, and you should be able to preview and check the data. It's possible that using .odc files might be enough. At the very least, you will need one for each of your data source files, and you should make the following changes: Change the name of the file in the following lines. Notice that the OLE DB provider expects "#" where a file name would normally have ".". You may find that "." works just as well. meta name=Table content=mmds#txt odc:CommandTextmmds#txt/odc:CommandText (I suspect, but have not checked, that Word looks at the first of those lines, not the last one, which is confusing because I would expect it to look at the last) Change the name of the folder that contains the file in the following lines: odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString As mentioned above, the .odc file is an HTML file with some JavaScript. It works together with a .htc file called DATACONN.HTC which you should find in your "My Data Sources" folder. If you copy DATACONN.HTC to c:\sample, then make sure nothing else has c:\sample\mmds.txt open (e.g. your mmmd.doc or mmmd.rtf document), then double-click on mmds.odc in Windows Explorer, Internet Explorer should open and display the contents of mmds.txt. This can be quite a useful debugging tool. See how you get on with that little lot, then see if you can apply it to any of your existing data sources. As for this question: Another yet untried solution is the one with a macro that does OpenDataSource. Primarily because I have no idea how to "disconnect" the data source from my document. Any hints? Manually, by clicking the first button in the Mail merge toolbar and selecting "Normal Word Document". Programmatically, via e.g. Sub DisconnectDS() ActiveDocument.MailMerge.MainDocumentType = wdNotAMergeDocument End Sub Hints on how to write the macro would also be welcome, I have found how to get to the editor (ALT-F8 etc) but I am not a VB programmer so it will take me a while to figure it out. OK, I'd prefer it if we looked at the other approach first. Peter Jamieson "Ulrika" wrote in message ... Hello again! I have had time to try removing the \mmquery field, and it seems like i am using the "Text converter" since I get a message that word can not find the data source. So, is there a way around this, or should I forget that solution? Another yet untried solution is the one with a macro that does OpenDataSource. Primarily because I have no idea how to "disconnect" the data source from my document. Any hints? Hints on how to write the macro would also be welcome, I have found how to get to the editor (ALT-F8 etc) but I am not a VB programmer so it will take me a while to figure it out. As always, thanks in advance! "Peter Jamieson" wrote: Yes, you have to hack the RTF file directly. If you check Word Tools|Options|General|Confirm conversions at open", when you open the .rtf you can open it as "Plain text" (you'll get a message that you can ignore when you save it). It's probably less confusing to use Notepad though. BTW I had a look at the OLE DB text thing and as far as I can tell, to avoid the delimiter dialog you do have to set up a SCHEMA.INI /and/ a .ODC file. So the wretched workaround ends up being quite complicated. We can go into the .odc stuff later. Peter Jamieson "Ulrika" wrote in message ... Thanks again - I still haven't had time to test anything, just glancing at the discussion group now and then. But for when I have a chance to test: exactly how do i remove the \mmquery field? By "hacking" into the rtf file with like Notepad, or by some more sophisticated Word stuff? BTW FYI again, the programmatic mail merge is done via Progress 4gl, so no VB-stuff here... :-) /U "Peter Jamieson" wrote: I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? Not really, because Word always uses an SQL SELECT statement even with text files. I just tried here and it looks as if a. if you connect using the Text converter, removing the RTF \mmquery field eliminates the prompt but causes causes Word to fail to find the source. b. if you connect using OLE DB, removing the \mmquery field works OK. However, since you usually see a prompt for a field delimiter character (comma/tab/other) whenever you open the .rtf file, you probably aren't using this method. NB this behaviour is fairly bizarre because it's clear from the ..rtf that Word stores the info. about which delimiter character it is using. (I haven't looked at the case where ODBC is used). If you don't know which you're using (it's not always obvious which Word uses), one difference is that the RTF for a text file connected via OLE DB has a {\mmodsotable filename#ext} field, and the RTF that uses the text converter does not. Also, when connecting in the first instance, the OLE DB connection pops up two dialog boxes asking for the field delimiter character. With the text converter, you see a box that asks for a field delimiter and a record delimiter. At the moment I don't know how Word decides which to use, but a. if the record delimiter is not carriage return/line feed (or something similar recognises by the OLEDB provider) Word cannot use OLE DB, as far as I know. The text converter lets you specify a number of other characters for that. b. recently I have found that using a SCHEMA.INI file to specify the delimiter character and sometimes other characteristics such as character set can make a significant difference in this area, even suppressing the prompt for a delimiter character. Previously I'd thought they were only used by the ODBC text driver. More on that if you need it. Sorry for the mass of acronyms and so on! Peter Jamieson "Ulrika" wrote in message ... Whew, thanks Peter for all the suggestions, and with my limited Word expertise it will take me a week or two to try them out... ;-) I will think about this and be back, but just FYI: our data source is a text file! That should simplify things, or..? /Ulrika "Peter Jamieson" wrote: So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? (Also see my nearby post). Interesting approach! What's more, it seems to work in at least some circumstances. It seems to me that in order for it to work, you need to remove the entire {\mmquery } field. However, since you then lose your query, it would only work if what Word does by default when it tries to connect using the remaining information available to it. If, for example, the data source is a ..mdb via an OLE DB connection, then the table or query name used for the connection is stored elsewhere in the {\mmodsotable } field, and in that case, without the \mmquery field a. you don't get the prompt b. Word issues "SELECT * FROM [the table in the mmodsotable field]" anyway So as long as you only need that default query, or can successfully modify the query by setting MailMerge.DataSource.QueryString , you should be OK. Worth verifying that on one of your target systems? The same thing may work for other types of data source, but I haven't looked. Further, even if Word does not store enough info to connect to a specific table, in many cases you may be able to use a .odc file to do so. Peter Jamieson "Ulrika" wrote in message ... Thanks for the answer Graham... ! One thing just occurred to me that I would appreciate feedback on. We use rtf-documents for our mail merge. This problem is not only related to KB 825765, but also to the new version of the RTF format, see KB artcle 922681. In the previous version, we did not have the field mmquery which contains an SQL query, which causes the security message. So would it be possbile to attack the problem from that angle? Like convincing Word to use an earlier RTF format, or to not use the mmquery field, or whatever? I have not looked in to this yet, I just thought of it. Maybe someone has already tried? "Graham Mayor" wrote: I believe you have it covered. Either you get the warning or you eliminate the warning through the registry. If you could eliminate the warning message in code then there would be no point in having the security check. I suppose you could write the change to the registry before running your code, then change it back afterwards See http://www.windowsdevcenter.com/pub/...html?page=last but I have not tried this to see how it works in practice and I would much prefer to live with what you have. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ulrika wrote: Hi, I work with an application that does programmatic mail merge. Recent security updates in Word has caused problems that we have now identified as caused by the issues described in KB 825765. When reading the article, my impression is that we have two choices: a) setting the application to display alerts, so that users will get the security message each time the application performs mail merge. b) disable the security message altogether using the workaround described in the article. Our customers, the owners of the application, do not want any of these two solutions. Instead, they want the application to hide the message, as it does today, but to answer "YES" to the question so that the mail merge is performed. But they want to keep the security message for mail merge activities outside the application, i.e. not turn it off altoghether. I have read the KB article, and many discussion group posts, and done some experimenting with the application, and my impression is still that we only have the two choices above. So, 1) Am I right or are there other solutions? 2) If I am right, are there any plans for the future to allow applications to hide the security message and answer "YES" to it? (If I can tell my customers that it is on its way, they might be able to live with the situation for a while...) 3) Does anyone have a clever solution that we haven't thought of? 4) Should I direct this question elsewhere, and if so where? Thanks in advance! |
|
#12
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
It worked! Thank you so much for the excellent instructions, detailed enough
so that I never got lost!!!!! I have followed your instructions and everything turned out just like you said. And theoretically I can see no problems in implementing this in our system. But I will need to test this, and also make sure this will work for the users with older versions of Word etc... but never mind that now. What I would like to ask is basically - what did I just do? I am not sure I understand the big picture... I think what I did was a) change the way the main document connects to the data source, so that the data source will still be found even though I have b) removed the mmquery field, which expresses the data source connection as an SQL query = the root of my problems Is that about right? Also, is this something that can be expected to "last" or is it a strange workaround that is "unstable" if you understand what I mean... And finally, are there details of this solution that I should "fine-tune", for example the "provider" ...? Thanks a million once again, you have saved me many hours of work!! /Ulrika "Peter Jamieson" wrote: Hi Ulrika, So, is there a way around this, or should I forget that solution? There may be a way around it, but because you have to change the way Word connects to the text data and the other methods do not work the same way as the text converter a. it may turn out not to be possible b. even if it is possible, it will be more complicated because you will need at least one extra file and probably two, and you will have to patch the Windows Registry if you are using an extension other than a standard one such as .txt or .csv c. you may face limitations you would prefer to avoid. As far as I know, it is unlikely to be be possible if a. your text file does not have a record delimiter that the OLE DB provider recognises, i.e. if you are using anything other than CR, LF or a recognised combination, it probably won't work. b. your text file has more than around 255 fields There may of course be other reasons why it won't work :-( On the other hand, if it works, it could be the best way forward as no VBA would be needed. Let's create a really simple example to work with (NB I will be away for a while in about 5 days' time so if you need to come back for more assistance, before or after that, please...). I would also like to go through some stuff that doesn't quite do what you want so you can see the effect of each of the components in this approach. This message contains stage one of the example. If your real data files are simple and have the delimiters and character encoding the OLE DB provider expects, you may be able to apply the approach described here to your text files without anything further. Otherwise, I'll do a second message with the remaining stuff to do with SCHEMA.INI. Let's suppose you have a folder called c:\sample and a delimited file in it called c:\sample\mmds.txt, mmds standing for "mail merge data source") containing some simple multiline data as follows: k,name,address 1,A Baker,"23 High Street Atown Middleshire" 2,C Draper,"25 Finkle Street Btown Topshire" You should be able to set that up by a. creating c:\sample b. copying/pasting the above text into Notepad, making sure there are no blank lines after Topshire", then saving the file as c:\sample\mmds.txt Now open Word and a blank document. Although the following should work wherever you save it, let's call it c:\sample\mmmd.doc (i.e. mail merge main document). For the moment, check Word Tools|Options|General|"Confirm conversions at open". You can uncheck it later when you don't need it any more. Enable Word's mail merge toolbar (Tools|Customize). Because we're trying to ensure that the merge works without any special changes in the Windows Registry, delete the SQLSecurityCheck value or set it to 1. Click the second button (Select Data Source), navigate to c:\sample, select mmds.txt, and click Open. You should see a "Confirm Data Source" dialog box, which will probably display at least the following options, probably with "Text Files (*.txt)" highlighted. OLE DB Database Files Text Files (*.txt) Delimited Text Files via ODBC (*.txt, *.csv) If your display differs substantially, let me know. Select OLE DB Database Files and click OK. You should see another dialog box titled "Text File Connection Parameters". Select "Comma", and ensure "First row of data contains column headers" is checked. Click OK. For some reason, the dialog box is then redisplayed (on a fast system you may not even notice). The values will probably be as you just entered them. Otherwise, make sure they are correct and click OK again. Word should connect to the data source. You should be able to use the Insert Merge Fields button (6th on the Mail Merge Toolbar) to insert the fields k, name and address, and the preview button () to verify that the data is as you expect. Save the document and close it. Then reopen it. You will probably see... a. the SQL Security check prompt. Click Yes b. the "Text File Connection Parameters" dialog, probably with the wrong delimiter selected. Select comma and ensure "First row of data contains column headers" is checked. Click OK. This time you probably won't see the dialog again. Now copy/paste the following text into Notepad and save it in c:\sample\mmds.odc. The text begins with html and ends with /html, and contains some Javascript. That's because I've provided it exactly as it was created by Word and the Data Link Editor - in fact, you can remove an awful lot of this stuff and it will still work in Word. You may have to fix some of it up, particularly if you see highlighted links. Let me know if you have problems. html head meta http-equiv=Content-Type content="text/x-ms-odc; charset=utf-8" meta name=ProgId content=ODC.Table meta name=SourceType content=OLEDB meta name=Table content=mmds#txt xml id=docprops/xmlxml id=msodcodc:OfficeDataConnection xmlns dc="urn:schemas-microsoft-comfficedc"xmlns="http://www.w3.org/TR/REC-html40" odc:Connection odc:Type="OLEDB" odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString odc:CommandTypeTable/odc:CommandType odc:CommandTextmmds#txt/odc:CommandText /odc:Connection /odc:OfficeDataConnection /xml style !-- .ODCDataSource { behavior: url(dataconn.htc); } -- /style /head body onload='init()' scroll=no leftmargin=0 topmargin=0 rightmargin=0 style='border: 0px' table style='border: solid 1px threedface; height: 100%; width: 100%' cellpadding=0 cellspacing=0 width='100%' tr td id=tdName style='font-family:arial; font-size:medium; padding: 3px; background-color: threedface' /td td id=tdTableDropdown style='padding: 3px; background-color: threedface; vertical-align: top; padding-bottom: 3px' /td /tr tr td id=tdDesc colspan='2' style='border-bottom: 1px threedshadow solid; font-family: Arial; font-size: 1pt; padding: 2px; background-color: threedface' /td /tr tr td colspan='2' style='height: 100%; padding-bottom: 4px; border-top: 1px threedhighlight solid;' div id='pt' style='height: 100%' class='ODCDataSource'/div /td /tr /table script language='javascript' function init() { var sName, sDescription; var i, j; try { sName = unescape(location.href) i = sName.lastIndexOf(".") if (i=0) { sName = sName.substring(1, i); } i = sName.lastIndexOf("/") if (i=0) { sName = sName.substring(i+1, sName.length); } document.title = sName; document.getElementById("tdName").innerText = sName; sDescription = document.getElementById("docprops").innerHTML; i = sDescription.indexOf("escription") if (i=0) { j = sDescription.indexOf("escription", i + 11); } if (i=0 && j = 0) { j = sDescription.lastIndexOf("/", j); if (j=0) { sDescription = sDescription.substring(i+11, j); if (sDescription != "") { document.getElementById("tdDesc").style.fontSize=" x-small"; document.getElementById("tdDesc").innerHTML = sDescription; } } } } catch(e) { } } /script /body /html ------------------------------------- Now, with your mmds.doc file open, Click the first button in the mailmerge toolbar (Main Document Setup) and select Normal Word Document. This removes the connection to the existing data source (and other info. such as sorts and filters, but not the Mail Merge fields). Click the second button (Select Data Source), locate the mmds.odc file you just saved, and open it. The "Confirm Data Source" dialog box should open, but this time there should be just one option, OLE DB Database Files Select that and click OK. You should not see the "Text File Connection Parameters" dialog box. Let me know if you do). You should be able to preview the data as before. Save and close mmmd.doc. Re-open it. You should see the SQL dialog. Click Yes. You should not see any other dialog boxes. Preview and check the data! Now save mmmd.doc as an rtf file, c:\sample\mmmd.rtf and close it. Re-open it as a text file using your preferred method, and locate and delete the \mmquery field, which should say {\mmquery SELECT * FROM `mmds#txt`} Make sure you don't delete anything else! Save and close the file. Now re-open the .rtf file in Word. You should see the Convert file dialog, and Rich text Format (RTF) should be displayed. If not, let me know, but try selecting the RTF option anyway and click OK. You should not see any other dialog, but the document should be connected to the data source, and you should be able to preview and check the data. It's possible that using .odc files might be enough. At the very least, you will need one for each of your data source files, and you should make the following changes: Change the name of the file in the following lines. Notice that the OLE DB provider expects "#" where a file name would normally have ".". You may find that "." works just as well. meta name=Table content=mmds#txt odc:CommandTextmmds#txt/odc:CommandText (I suspect, but have not checked, that Word looks at the first of those lines, not the last one, which is confusing because I would expect it to look at the last) Change the name of the folder that contains the file in the following lines: odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString As mentioned above, the .odc file is an HTML file with some JavaScript. It works together with a .htc file called DATACONN.HTC which you should find in your "My Data Sources" folder. If you copy DATACONN.HTC to c:\sample, then make sure nothing else has c:\sample\mmds.txt open (e.g. your mmmd.doc or mmmd.rtf document), then double-click on mmds.odc in Windows Explorer, Internet Explorer should open and display the contents of mmds.txt. This can be quite a useful debugging tool. See how you get on with that little lot, then see if you can apply it to any of your existing data sources. As for this question: Another yet untried solution is the one with a macro that does OpenDataSource. Primarily because I have no idea how to "disconnect" the data source from my document. Any hints? Manually, by clicking the first button in the Mail merge toolbar and selecting "Normal Word Document". Programmatically, via e.g. Sub DisconnectDS() ActiveDocument.MailMerge.MainDocumentType = wdNotAMergeDocument End Sub Hints on how to write the macro would also be welcome, I have found how to get to the editor (ALT-F8 etc) but I |
|
#13
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
|
KB 825765 - just making sure...
Hi Ulrika,
I have to be quick and can follow this up when I'm back "at my desk" in a few days. I think what I did was a) change the way the main document connects to the data source, so that the data source will still be found even though I have b) removed the mmquery field, which expresses the data source connection as an SQL query = the root of my problems Is that about right? Yes. This approach uses the Jet (Access) OLE DB provider to get the data. Whenever Word 2002/2003 uses OLE DB, it uses an internal object called ODSO Office Data Source Object) to make the connection. When it does so, it stores information about the specific data source in more than one place in the .rtf, and (in essence) reconstructs the necessary SQL statement when it next connects. Also, is this something that can be expected to "last" or is it a strange workaround that is "unstable" if you understand what I mean... Unfortunately, all workarounds of this kind are at the mercy of Microsoft. The most likely reason for this to stop working is that someone at Microsoft notices it (perhaps even because of this thread), decides it is a loophole that needs to be closed for security reasons, and "fixes" the problem in a future patch. If you move to Word 2007, you may also find that everything changes because the "Jet" OLE DB pprovider is replaced in that version by a modified version called ACE, which uses a different Provider name. Ultimately, the "safe" fix is to make that registry change. But it is understandable that organisations do not particularly wish to do so. And finally, are there details of this solution that I should "fine-tune", for example the "provider" ...? When you use a .odc file, Word uses all the information in the ConnectionString in the .odc. However, ODSO actually adds in a minimum set of other OLE DB settings and you will probably see them in the .rtf. I don't think you need to try to fix that. You can remove a lot of stuff in the .odc if you just want to use it with Word. For example, you can cut out everything after the closing /html. I forget what else, but will get back to this. Again, the argument for keeping the full .odc is that Microsoft might conceivably change ODSO so that it requires a more complete .odc. Peter Jamieson "Ulrika" wrote in message ... It worked! Thank you so much for the excellent instructions, detailed enough so that I never got lost!!!!! I have followed your instructions and everything turned out just like you said. And theoretically I can see no problems in implementing this in our system. But I will need to test this, and also make sure this will work for the users with older versions of Word etc... but never mind that now. What I would like to ask is basically - what did I just do? I am not sure I understand the big picture... I think what I did was a) change the way the main document connects to the data source, so that the data source will still be found even though I have b) removed the mmquery field, which expresses the data source connection as an SQL query = the root of my problems Is that about right? Also, is this something that can be expected to "last" or is it a strange workaround that is "unstable" if you understand what I mean... And finally, are there details of this solution that I should "fine-tune", for example the "provider" ...? Thanks a million once again, you have saved me many hours of work!! /Ulrika "Peter Jamieson" wrote: Hi Ulrika, So, is there a way around this, or should I forget that solution? There may be a way around it, but because you have to change the way Word connects to the text data and the other methods do not work the same way as the text converter a. it may turn out not to be possible b. even if it is possible, it will be more complicated because you will need at least one extra file and probably two, and you will have to patch the Windows Registry if you are using an extension other than a standard one such as .txt or .csv c. you may face limitations you would prefer to avoid. As far as I know, it is unlikely to be be possible if a. your text file does not have a record delimiter that the OLE DB provider recognises, i.e. if you are using anything other than CR, LF or a recognised combination, it probably won't work. b. your text file has more than around 255 fields There may of course be other reasons why it won't work :-( On the other hand, if it works, it could be the best way forward as no VBA would be needed. Let's create a really simple example to work with (NB I will be away for a while in about 5 days' time so if you need to come back for more assistance, before or after that, please...). I would also like to go through some stuff that doesn't quite do what you want so you can see the effect of each of the components in this approach. This message contains stage one of the example. If your real data files are simple and have the delimiters and character encoding the OLE DB provider expects, you may be able to apply the approach described here to your text files without anything further. Otherwise, I'll do a second message with the remaining stuff to do with SCHEMA.INI. Let's suppose you have a folder called c:\sample and a delimited file in it called c:\sample\mmds.txt, mmds standing for "mail merge data source") containing some simple multiline data as follows: k,name,address 1,A Baker,"23 High Street Atown Middleshire" 2,C Draper,"25 Finkle Street Btown Topshire" You should be able to set that up by a. creating c:\sample b. copying/pasting the above text into Notepad, making sure there are no blank lines after Topshire", then saving the file as c:\sample\mmds.txt Now open Word and a blank document. Although the following should work wherever you save it, let's call it c:\sample\mmmd.doc (i.e. mail merge main document). For the moment, check Word Tools|Options|General|"Confirm conversions at open". You can uncheck it later when you don't need it any more. Enable Word's mail merge toolbar (Tools|Customize). Because we're trying to ensure that the merge works without any special changes in the Windows Registry, delete the SQLSecurityCheck value or set it to 1. Click the second button (Select Data Source), navigate to c:\sample, select mmds.txt, and click Open. You should see a "Confirm Data Source" dialog box, which will probably display at least the following options, probably with "Text Files (*.txt)" highlighted. OLE DB Database Files Text Files (*.txt) Delimited Text Files via ODBC (*.txt, *.csv) If your display differs substantially, let me know. Select OLE DB Database Files and click OK. You should see another dialog box titled "Text File Connection Parameters". Select "Comma", and ensure "First row of data contains column headers" is checked. Click OK. For some reason, the dialog box is then redisplayed (on a fast system you may not even notice). The values will probably be as you just entered them. Otherwise, make sure they are correct and click OK again. Word should connect to the data source. You should be able to use the Insert Merge Fields button (6th on the Mail Merge Toolbar) to insert the fields k, name and address, and the preview button () to verify that the data is as you expect. Save the document and close it. Then reopen it. You will probably see... a. the SQL Security check prompt. Click Yes b. the "Text File Connection Parameters" dialog, probably with the wrong delimiter selected. Select comma and ensure "First row of data contains column headers" is checked. Click OK. This time you probably won't see the dialog again. Now copy/paste the following text into Notepad and save it in c:\sample\mmds.odc. The text begins with html and ends with /html, and contains some Javascript. That's because I've provided it exactly as it was created by Word and the Data Link Editor - in fact, you can remove an awful lot of this stuff and it will still work in Word. You may have to fix some of it up, particularly if you see highlighted links. Let me know if you have problems. html head meta http-equiv=Content-Type content="text/x-ms-odc; charset=utf-8" meta name=ProgId content=ODC.Table meta name=SourceType content=OLEDB meta name=Table content=mmds#txt xml id=docprops/xmlxml id=msodcodc:OfficeDataConnection xmlns dc="urn:schemas-microsoft-comfficedc"xmlns="http://www.w3.org/TR/REC-html40" odc:Connection odc:Type="OLEDB" odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString odc:CommandTypeTable/odc:CommandType odc:CommandTextmmds#txt/odc:CommandText /odc:Connection /odc:OfficeDataConnection /xml style !-- .ODCDataSource { behavior: url(dataconn.htc); } -- /style /head body onload='init()' scroll=no leftmargin=0 topmargin=0 rightmargin=0 style='border: 0px' table style='border: solid 1px threedface; height: 100%; width: 100%' cellpadding=0 cellspacing=0 width='100%' tr td id=tdName style='font-family:arial; font-size:medium; padding: 3px; background-color: threedface' /td td id=tdTableDropdown style='padding: 3px; background-color: threedface; vertical-align: top; padding-bottom: 3px' /td /tr tr td id=tdDesc colspan='2' style='border-bottom: 1px threedshadow solid; font-family: Arial; font-size: 1pt; padding: 2px; background-color: threedface' /td /tr tr td colspan='2' style='height: 100%; padding-bottom: 4px; border-top: 1px threedhighlight solid;' div id='pt' style='height: 100%' class='ODCDataSource'/div /td /tr /table script language='javascript' function init() { var sName, sDescription; var i, j; try { sName = unescape(location.href) i = sName.lastIndexOf(".") if (i=0) { sName = sName.substring(1, i); } i = sName.lastIndexOf("/") if (i=0) { sName = sName.substring(i+1, sName.length); } document.title = sName; document.getElementById("tdName").innerText = sName; sDescription = document.getElementById("docprops").innerHTML; i = sDescription.indexOf("escription") if (i=0) { j = sDescription.indexOf("escription", i + 11); } if (i=0 && j = 0) { j = sDescription.lastIndexOf("/", j); if (j=0) { sDescription = sDescription.substring(i+11, j); if (sDescription != "") { document.getElementById("tdDesc").style.fontSize=" x-small"; document.getElementById("tdDesc").innerHTML = sDescription; } } } } catch(e) { } } /script /body /html ------------------------------------- Now, with your mmds.doc file open, Click the first button in the mailmerge toolbar (Main Document Setup) and select Normal Word Document. This removes the connection to the existing data source (and other info. such as sorts and filters, but not the Mail Merge fields). Click the second button (Select Data Source), locate the mmds.odc file you just saved, and open it. The "Confirm Data Source" dialog box should open, but this time there should be just one option, OLE DB Database Files Select that and click OK. You should not see the "Text File Connection Parameters" dialog box. Let me know if you do). You should be able to preview the data as before. Save and close mmmd.doc. Re-open it. You should see the SQL dialog. Click Yes. You should not see any other dialog boxes. Preview and check the data! Now save mmmd.doc as an rtf file, c:\sample\mmmd.rtf and close it. Re-open it as a text file using your preferred method, and locate and delete the \mmquery field, which should say {\mmquery SELECT * FROM `mmds#txt`} Make sure you don't delete anything else! Save and close the file. Now re-open the .rtf file in Word. You should see the Convert file dialog, and Rich text Format (RTF) should be displayed. If not, let me know, but try selecting the RTF option anyway and click OK. You should not see any other dialog, but the document should be connected to the data source, and you should be able to preview and check the data. It's possible that using .odc files might be enough. At the very least, you will need one for each of your data source files, and you should make the following changes: Change the name of the file in the following lines. Notice that the OLE DB provider expects "#" where a file name would normally have ".". You may find that "." works just as well. meta name=Table content=mmds#txt odc:CommandTextmmds#txt/odc:CommandText (I suspect, but have not checked, that Word looks at the first of those lines, not the last one, which is confusing because I would expect it to look at the last) Change the name of the folder that contains the file in the following lines: odc:ConnectionStringProvider=Microsoft.Jet.OLEDB .4.0;User ID=Admin;Data Source=C:\sample\;Mode=Read;Extended Properties="HDR=Yes;";Jet OLEDB:Engine Type=96;/odc:ConnectionString As mentioned above, the .odc file is an HTML file with some JavaScript. It works together with a .htc file called DATACONN.HTC which you should find in your "My Data Sources" folder. If you copy DATACONN.HTC to c:\sample, then make sure nothing else has c:\sample\mmds.txt open (e.g. your mmmd.doc or mmmd.rtf document), then double-click on mmds.odc in Windows Explorer, Internet Explorer should open and display the contents of mmds.txt. This can be quite a useful debugging tool. See how you get on with that little lot, then see if you can apply it to any of your existing data sources. As for this question: Another yet untried solution is the one with a macro that does OpenDataSource. Primarily because I have no idea how to "disconnect" the data source from my document. Any hints? Manually, by clicking the first button in the Mail merge toolbar and selecting "Normal Word Document". Programmatically, via e.g. Sub DisconnectDS() ActiveDocument.MailMerge.MainDocumentType = wdNotAMergeDocument End Sub Hints on how to write the macro would also be welcome, I have found how to get to the editor (ALT-F8 etc) but I |
| Reply |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Forum | |||
| Making C.V | Microsoft Word Help | |||
| Making a catalogue | Mailmerge | |||
| Tab down making labels? | Microsoft Word Help | |||
| How do you go about making a c.v. | New Users | |||
| Making TOC Hyperlinks | Microsoft Word Help | |||
Linear Mode
