From my VB.net application I manage to create a database.
I can also create tables, with all kinds of datatypes in them. (with much thanks to stackoverflow's contributors!)
so far so good...
but how do I set the datatype MEMO to accept rich text?
basically how do I code to get : (MS Access snippet)
I'm sure it is a simple addition to the regular CREATE TABLE business - but I don't know what!
any hints would be most appreciated!
You don't have to do anything to make the Memo data type accept RTF data. RTF is text and a Memo column stores text. Job done. Many of those fields you're setting on the column are about how Access DISPLAYS the data within Access itself, not how it stores it. If you're using the MDB or ACCDB file simply as storage and the data only gets displayed in your application then that Text Format is irrelevant.
I'm trying to do a Word MailMerge via VBA from my Access project. I created a clsWordMerge class so I could declare the Word application WithEvents, and take advantage of Word's MailMerge events, mainly the AfterMerge event.
Everything works fine, and I get the finished Word documents created, except that the source fields containing RTF data end up in the document not as formatted text, but instead the RTF codes and data:
<div><font face="Times New Roman" size=3 color=black>This is my <strong><em>test </em></strong>paragraph.</font></div>
Where I would expect to see:
This is my test paragraph
This happens whether I do a mail merge using a CSV file for my data source or an Access table.
So is there any way to correct this, and show the formatted data? I have access to all of the MailMerge events that Word provides.
Thanks..
No, there's no way to merge in RTF and have it display as Word content. RTF is not Word's native file format - a converter is required to display RTF as Word content.
Mail merge literally displays the data text, as it appears in the data source. There are no "advanced features" that enable selectively formatting the mail merge result.
Also, based on painful experience, relying on MailMergeAfterMerge is not advisable. When it was introduced, I tried it, was enthusiastic... until it started failing. The event is unpredictable and not reliable.
Given your requirements, a fully VBA-driven data transfer from Access to Word is a better investment of time and energy.
It probably can be done in certain circumstances, but I agree with Cindy Meister that the Mail Merge Events have not proven reliable (unless they have been fixed - I haven't actually used them for years). The following description of real and likely problems that I have previously encountered when trying this may help:
Not sure any of it can be done if you are merging to Email.
AFAICR the event you are likely to need (MailMergeBeforeRecordMerge) only fires each time Word processes the Main Document, not each time it processes a record in the data source. So if your Mail Merge Main Document "consumes" more than one Data Source record, e.g. because it uses { NEXT } or { NEXTIF } fields, it may be very difficult to get MaiMergeBeforeRecordMerge to do what you need. If I am right about that, that would be enough to put me off making the attempt.
in order to insert your "RTF", you must either
a. Have code that can interpret the "RTF" encoding and do all the right things necessary to insert it in your document, or
b. Have code that saves the "RTF" to an external file, then uses (say) Range.InsertFile to insert it and have Word interpret its contents, or perhaps
c. Use the clipboard to help you do the conversion.
If any of your rich text fields actually contained RTF, (a) would be difficult unless you could find a suitable library to help you. But in fact your sample shows a typical Access rich text field value, which is HTML-like. In fact, I think it is all standard HTML tagging that Word can interpret, but I don't know for sure. That could be much easier to interpret, especially if you only need the plain text (at its simplest, you might be able to throw away the tagging and insert the result.
If your rich text is longer than 255 characters (including the markup), Word's Document.MailMerge.DataSource.DataFields("the case-sensitive field name as Word sees it").Value will be truncated. So if you need the whole of the text or more of it, you'll have to get it somewhere else
The value inserted in the document using a { MERGEFIELD } field is not truncated to 255 characters so you may be able to get the value from the document. Word MailMerge may impose another limit (can't remember, perhaps 64Kb for an OLE DB connection, perhaps less, or perhaps there is a length limit for the data as a whole.
If you can't get the data from the document, you can get it directly from Access. Probably rather easily if your code is running in Access, but it can be done by using ADODB or perhaps ADO from Word VBA code. Your Mail Merge Data Source will need to retrieve the key fields of the record if you want to do that reliably. During development, if your application is running from Access but you are using VBA code in Word, you will probably also need to make sure that you save your Access database each time you modify your Access VBA code, otherwise Access opens the database exclusively and Word won't be able to retrieve data from it.
If you need to use (b) or (c) to save your HTML to a file then you may need to surround the HTML that you get from Access with tags and possibly tags to get Word to recognise the HTML. You could use Scripting.FileSystemObject to save the text, or perhaps ADODB.Stream if you are already using ADODB to retrieve Access data.
You should be able to use VBA Range.InsertFile to insert it, as long as you have some placeholder that tells you what to put it. Or you could use an INCLUDETEXT field and ensure that your Event code updates that field. A snag with the INCLUDETEXT approach is that if you merge to a new document, the INCLUDETEXT fields remain in the document so if you update them, they will all end up with the same result if you do not also create a new file for each source record.
i.e. quite a lot to think about!
I have a several sharepoint tables, some of which use lookup fields (I know I know they are bad but for this database we need the lookup fields to be in place).
If I manually link the table via the top ribbon it imports the table fine.
If i use VBA and DoCmd.TransferSharePointList acLinkSharePointList then it returns all lookup columns as "Short Text" instead of a lookup field.
I don't understand why it works perfectly when done manually but messes up when done through VBA. Anyone have any ideas? I can't find anyone with a similar issue on google.
Solved it.
You want to put "False" in the "GetLookupDisplayValues" criteria shown in the link below
https://learn.microsoft.com/en-us/previous-versions/office/developer/office-2007/bb238962(v=office.12)
I am having issues figuring out the best way to do this:
I have a word template for an interview pre-night. What I need to do is fill out the word template with the interviewer and the people who are interviewing them. There will always be 1 interviewee but up to 12 interviewers. The part giving me issue is that there will not always be 12 interviewers so the area that the data is moved to needs to be dynamic. Should I create a table or bookmarks in Word and use VBA to move the data, or design the report in Access? Thanks for your help!
I am going to assume that what you are trying to do is complicated enough that "mail merge" won't work for you.
It really depends on whether you need the end result to be a Word document or an Access report. Both easily convert to PDF for document archiving. If you prefer to work with Word, add the key fields into your document with all the formatting necessary and then use VBA to do a search replace.
Two ways you could go about dealing with the 1-12 interviewers issue:
Use VBA to create one long segment containing all interviewers as a
single "field".
Add 12 sets of key fields and use search/replace
(through VBA of course not manually) to fill in the exiting
interviewer info and delete the key fields for the non-existing ones.
I have an Access 2007 data entry form that is bound to a table that is used solely as a holding station for the data until it is reviewed and appended to the permanent tables. There are several fields in the table (and thus form) that have multi-value selections (derived from a look-up table query). The user does not care if the data is searchable so storing in the text field as a long list is fine. The problem is with appending. I cannot append multi-value lists to a table.
I noticed that if I save the table as an excel spreadsheet and then import it back into a table with the same database structure as the exporting table but without multi-value combo boxes for those fields requiring multi-values (they are now just text boxes) that the list is there and formatted the way I want.
So I am thinking, what code is Access using to export the correct values to Excel and could I just use similar coding to append to the permanent tables (which don’t have to have the corresponding text fields formatted as a multi-value list) instead of having to export to an Excel file and then import this back into a new template? Please note that although some of the lists are only 10-15 options, one list has over 50 possible selections to choose from.
I am just trying to make a user friendly data entry interface without scores of vba coding (which I am a newbie at). Alternate ideas are welcome.
Internally, Access is doing just what Allen Browne's ConcatRelated function does. Fortunately, Allen's code will handle multi-valued fields so you can just use it in a query like this
INSERT INTO MainTable ( MealType, Meats )
SELECT MealType, ConcatRelated("Meats","TempTable","TempID=" & [TempID]) AS Expr1
FROM TempTable;
where [MainTable].[Meats] is Text(255) and [TempTable].[Meats] is a multi-valued Lookup field.