467,864 Members | 1,797 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,864 developers. It's quick & easy.

Copy a large textbox value from a form to a memo field (Access 2003)

I am trying to copy a textbox field on a form (which basically contains the body of a letter) into a memo field in a table (Access 2003) for later printing later. Of course Access queries/SQL will not copy that many characters. I have considered breaking the text box into blocked character sets, but it seems there must be an easier method. Thanks so much for your help!
Oct 22 '08 #1
  • viewed: 2586
5 Replies
Is the textbox bound to a field in a table. If not why not simply attach it to the memo field in the table you are trying to copy the data to and then it will automatically be saved where you want it.
Oct 22 '08 #2
Is the textbox bound to a field in a table. If not why not simply attach it to the memo field in the table you are trying to copy the data to and then it will automatically be saved where you want it.
In a nutshell, no, the form/textbox is not bound (actually no forms in this system are bound due to the server tables and number of users). Also, the system would only - possibly - be creating new records (multiple letters/forms created for our applicants with a single action based on selections from other screens). The save/print/add to batch is from a 'print/save form' opened from any number of other forms and relating to different back-end tables on our servers. It is also dependent on the user even selecting [ add to batch printing ]. The non-editable-standard forms are easy as I need only capture the data necessary to recreate the form (these aren't even shown to the users). However, the letters are a bit tougher as they may be personally edited by the user while the save/batch print function must be in a single step (calls to various modules) for all items created (possibly up to 20 pages of different letters/forms for each applicant at a single time). In this scenario, I donít believe binding would be practical.

More background: Working from an .MDE front-end local Access program - there are 20+ users on the system - simultaneously - which dynamically creates letters/forms for our clients. The system then updates backend data bases, electronically orders medical requirements from our 3rd party vendors and updates itself as to the requirements ordered and then awaits electronic results from our vendors.

It does an incredible job with work flow, time management, cost analysis, employee time standards, auto-email notifications to clients, auto follow-ups and barcode tracking of 2-3000 clients each month. It seems rather humorous to me that saving a letter is difficult with what the system already does.
Oct 22 '08 #3
Expert Mod 16PB
Having a look at this I guess you have straightforward access to the data in the control, and I doubt you are having difficulty with recordset processing, so where exactly is the specific problem located?
Oct 25 '08 #4
First off, thanks for the responses!

The nutshell of the problem WAS I could not move 19k characters to a server table directly from a single textbox on a form. After 510 characters, I basically got junk.

Since SQL has no issues moving table to table, my solution was to create a 'local' table with a hidden form bound to it as this allowed the forms contents to be copied - in it's entirety - to the local table memo field. In turn, the module [called to open the form] then copies that record to the server table, afterwards deleting it [the temp record] from the local table and closes the form.

The first response [to my problem] gave me the idea to this workaround. The time it takes to accomplish this is unnoticeable by the users.
Oct 29 '08 #5
Expert Mod 16PB
Excellent :)

Thanks for the update.

Welcome to Bytes!
Oct 30 '08 #6

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

6 posts views Thread by Oren | last post: by
25 posts views Thread by tekctrl | last post: by
reply views Thread by jack112 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.