Having converted a number of fields in a table tblSource to Rich Text memos, I'm getting an error 3188 in the following circumstances.
Main form has a subform open (frmSource) bound to qrySource. qrySource pulls in some fields from tblSource and adds a calculated field which concatenates the (newly-minted) rich-text memo fields (SD1 to SD20) so that the result can be displayed in a single text box on frmSource called Citation.
If the user wishes to edit SD1 to SD20, they double-click on the Citation field and a modal form frmCitation opens up displaying the SD fields for editing. frmCitation is bound to qryCitation which pulls the SD fields and a couple of others out of tblSource. When finished, they close frmCitation. When SD1 etc were text fields, the tblSource record was updated successfully. However, now they're memo fields, I'm hitting VBA error 3188 ("Could not update; currently locked by another session on this machine.").
Searching on the Internet suggests that this is a common issue with Rich Text memos when a memo size exceeds 2k (limitation possibly due to Access edit buffer size?), so I'm looking for ways to work around it.
One option would be be to split tblSource into two tables tblSource and tblCItation with a one-to-one relationship between them, then base qrySource on tblSource and qryCitation on tblCitation, but that's fairly major surgery with knock-on effects in a number of other places in the application.
Another option is to limit the size of all the memo fields on this form (as per Rich text input into limited length text field in Access 2010), but there's one field for which that wouldn't be acceptable to the users.
Is there another technique I could explore?
Per the following MS Link: http://answers.microsoft.com/en-us/office/forum/office_2007-access/memo-field-could-not-update-currently-locked-by/d5c8163a-7ce5-484f-80d4-98c1a8c92160
near the bottom, they suggest the limit is 2,000 characters.
Not that it helps, but could you add code to the 'before update' to display what the new size should be wnen concatenated? May help to figure a solution...
Be sure to save the form before making any changes with:
If Me.Dirty Then Me.Dirty = False
Workaround 1: Try to update not a field of an underlaying query or table, but a field of the form's Recordset. For example:
With Me.Recordset
.Edit
!MemoField = "TEXT ADDED HERE <- " & !MemoField
.Update
End With
Workaround 2: If you need to update not form's Recordset, but any other Recordset, try to unbind the TexBox, make the update and then make the TextBox binded back again.
I had the same issue and I closed all other open tabs (tables, etc...) and tried again. That worked fine.
I had this problem years ago & was revisiting in case it as not an issue anymore, but seems it is.
I had a list/column form of emails inc a field with a large rft memo.
I wanted to click on a record to bring up the one email in single form
The only way I could get it to work was Open the Single form & immediately close the multi row form, on exiting the single had to load the list again using bookmarks etc. to return to where I wanted to be, a real pain.
Especially as like now I would like to be able to access the the list whilst still on the single form, hence the revisit, instead looks like I will have to save all the list'id somehow. Dooable but a lot more programming that I think should be necessary.
Related
I have an unbound textbox to accept the delete older than: number of days. It is in the report header. I set it to 30 days but I want the user to be able to change it. I was banging my head trying to figure out why entering 40 was not being accepted and it reverted back to 30 every time. I finally decided on using the lost_focus event to set .value to .text. That worked.
Further research showed that when the textbox get's focus text and value are both the same, 30 in my case. Changing the number in the text box to 40 shows the values of text at 40 and value at 30. Unless I specifically set Value to the value of text Access changes text to the value of value. This is different behavior than other places in Access such as forms.
Can anyone tell me why this might be? I can't find any setting that might do this. Is it because it's in a report header? what is the difference between this and every other text box I've ever used?
From a "best practices" viewpoint, Access Reports are not intended to be used interactively despite the ability to manipulate some unbound controls. Although workarounds can be implemented that function sufficiently well, such solutions are often incomplete and buggy and function differently depending on the active view: Report View vs. Print Preview. Appropriate design patterns include using Access Forms for specifying report options which then open the Report in a static configuration.
This may not satisfy the question "Why?" if seeking a deeper answer as to why Microsoft implemented inconsistent binding behavior in Access, or why they allowed interactive controls in reports at all if they don't behave the same way as in forms. But Access has plenty of other quirky behaviors that have no known/published explanation.
Regarding the priority of the Value property updating the Text property (and not vice versa): Value is the key field because it contains the actual data for the control (bound or unbound). Although it is natural to have a single control for both display and input (uh, that's how almost all controls work), the processes of displaying data and parsing user input are two distinct functions. The visual representation returned by the Text property can be manipulated using the various formatting properties, and technically could display an incomplete representation of the underlying Value data. If there are any conflicts between the stored Value property and the Text property, it is natural that the existing Value property has precedent.
My guess is that the automatic binding behavior was "relaxed" for reports to allow more flexible custom reporting output. First consider an Access Form in Datasheet view: An unbound Form control shows the same value for all records. Even if the control is edited while on a particular row, the updated value is displayed for all rows. The same control object is essentially repainted for each row and there is no concept of individual instances of the control that can hold different values. Bound controls have built-in code that repaint the control with data from the particular row, but there are still not multiple instances each "holding" the individual values. The visual output differs from an intuitive object-oriented paradigm where our minds what to assign each visual row its own in-memory instance of the controls--it just doesn't work like that in Access.
Unlike the Form behavior just described, the Report's Print Preview (and actual printed output) allows unbound controls to display different data per row using the Detail_Format() event. Within the Detail_Format() event, one can set the Value property of a control at which time the Text property is automatically updated according to various formatting properties. This update Text is then output for the current row. Perhaps (just guessing) that this behavior would not function properly if the Text property updated the value property. I suspect it would cause recursive events during report generation. Because reports are not meant to be interactive, relevant text-input parsing code was "disconnected" so that it doesn't behave like on a form.
All that explanation doesn't make Access any less frustrating nor remove its limitations, but at least learn to adapt and design things in the "Access-esque" way rather than fighting it.
your best bet is to design a form with the unbound combo boxes and have your data displayed in a subreport. I like to design my reports so that when values are updated the query for the recordsource of the report is generated doing this requires 2 queries to exist, one with all data possible and a filtered one as subreport recordsource. This will control the data for printing and also allow users to close or navigate away from the report and return to the data later.
Private Sub ComboBox1_AfterUpdate()
Dim Query1 as Object
Dim Temp_Name as Variant
Temp_Name = SubReport.SourceObject
SubReport.SourceObject = Empty
Set Query1 = Me.Form.Application.DBEngine.Workspaces(0).Databases(0).QueryDefs ("SubReport_Query")
Query1.SQL = "Select * Unfiltered_Query WHERE Field1 <= " ComboBox1 & ";"
SubReport.SourceObject = Temp_Name
End Sub
I have a table that contains items, their location, and an attachment photo of the item. The location is set up by row #-shelves #-shelf #. For example 2-3-4 would be in the second row on the third set of shelves on the fourth shelf down. I have another form that allows users to search by shelf. Basically, they enter the first two numbers and I do this.
DoCmd.OpenForm "fReview", , , "Location Like '" & locStr & "*'"
Where 'locStr' is the string containing 2-3 (the first two numbers), and when the form fReview opens, it should show all items on all shelves of the second row, third shelf unit.
This part works just fine. However, when fReview opens, the image part of the attachment field that I put on the form stays blank. The rest of the fields populate with no problems. When I close the form and open it again normally (with no Where condition), the image works perfectly (although it does blink a few times like it is refreshing multiple times which is weird). The form is linked to the table, so it should all be directly linked, so I don't know what's happening.
So, I created a brand new tiny database to test some things, and figured out my problem. Thought I'd share it, just in case somebody eventually had the same problem I did. It was actually pretty simple.
When I added the attachment field to my form, I just dragged it over from the "Add Existing Fields" bar. This linked the Attachment.FileData as the control source for the field, which seemed ok. Turns out that that isn't right for some reason. If you change the control source to simply be the field name, it works.
So I have an input form that I want to use to update a table with certain fields of information. I have the ID of the record automatically coming up in a text box. I have three text boxes that I need to add to the table (excluding the ID) on a button click.
Name
Date
Method
are the field names.
As_Name
As_Date
As_Method
are the text box names
The table name is POC, and the ID is POC_ID (its an autonumber).
So I do not want these objects (text boxes) to be bound to the table because this is a little separate "pop-up" form that comes from a form that the table, and I only want the input to be relative to the POC_ID that is already selected via the original form.
So how do I write the vba for this to 1)check to make sure that records do not already exist....2)update the fields (listed above) with data input from the text boxes(listed above). I want to be able to use this with a button click....
EDIT:
actually it is one table not two; i have two forms that I want to be able to send information to the same table (different information though). this db was already built by someone else and know I have been deamed to take it over.
I need to add a second little pop up form for additional information to be added based on new requirements (there is literally no where for me to place this on the other one). I have already done that, and used a suggested object approach to reference the first forms (from which this second "pop-up" form springs from) to add the relative id fields. Now I have this second little pop up form that just asked three values to be inputted (which are the ones listed above).
I just simply do not know how to link the text box, with a field so that once a user enters in the information, clicks "save" it saves the information to the table relative to the TripID that is there (one mentioned above). the only way I know how to get the text boxes to save data to the table is to use the builder/wizard when I create a new one.
I would like to learn how to link an object (text box, cmb, list) etc on a form, to a table with an "On Click" method so that I can use a save button. Basically that is it!
The OpenForm method of DoCmd allows for several arguments, including Where and Openargs. You can take advantage of these.
However, something seems to be quite wrong with your table design in that you appear to be holding the same information in two tables and for no stated reason. Have you read http://www.r937.com/relational.html?
I would suggest that the design you need probably only includes a numeric field POC_ID that is a foreign key to the main table.
Still not sure I understand your situation, but let me offer the outline of an answer. If my outline is not close enough, please explain where I went astray.
Your parent form, frmParent, has a command button (cmdMoreFields) which opens the child form (frmChild) where you will enter values for 3 additional fields in the record currently displayed in frmParent. After the user enters those values in frmChild (in text box controls named As_Name, As_Date, and As_Method), she will click a command button (cmdSave) to store those values to fields (Name, Date, and Method) in table POC, and close frmChild. Also, frmParent includes a text box (txtPk_field) which holds the value for the primary key (field pk_field in table POC) of the current record.
However, I'm not sure which field/control you're using for txtPk_field, and doubt that value is available if the the current record has not yet been saved. So, I'll suggest this code for the cmdMoreFields "on click" event:
If Me.Dirty Then Me.Dirty = False
DoCmd.OpenForm "frmChild"
In the "on click" event of cmdSave (on frmChild), try code similar to:
Dim strSql As String
strSQL = "UPDATE POC SET [Name] = """ & Me.As_Name & """, [Date] =#" _
& Me.As_Date & "#, Method = """ & Me.As_Method & """ WHERE pk_field = " _
& Forms!frmParent.txtPk_field & ";"
Debug.Print strSql
CurrentDb.Execute strSql, dbFailOnError
DoCmd.Close
If that approach works, consider passing the pk_field value to frmChild with Openargs, as Remou suggested.
Note: I assumed the data type for Name is text, Date is date/time, and Method is text. You will have to change the UPDATE statement delimiters for any fields whose data types differ from my guesses.
My question is twofold.
I have around twenty assorted tables in a database. The table layouts are diverse; the one common thread is that all of them have a 'County' field.
I need to set up a series of reports which allow a user to select a county from a drop-down box, triggering the report to run and return only records attached to that particular county.
This is doable at the datasheet level using a filter-by-form, but that's pretty clunky and I have several tables/queries which will need this same county filter.
I may be halfway there with the following:
Create an unbound form.
Add a combo box.
Set the Row Source of the combo box to include the County field.
Set its Bound column to 1.
Set its Column Count property to 2.
Set the Column Width property to 0";1"
Name the Combo Box 'ChooseCounty'.
Add a Command Button to the form.
Code the button's click event as follows:
(Note: To write the code, in Form Design View select the command button. Display the button's property sheet.
Click on the Event tab.
On the On Click line, write:
[Event Procedure]
Click on the little button with the 3 dots that appears on that line.
When the code window opens, the cursor will be flashing between two already existing lines of code.
Between those lines, write the following code.)
Me.Visible = False
Close the Code window.
Name this form 'ChooseCounty'.
In the Query that is the Report's Record Source [County] field
criteria line, write:
forms!ChooseCounty!ChooseCounty
Next, code the Report's Open event:
(Using the same method as described above)
DoCmd.OpenForm "ChooseCounty", , , , , acDialog
Code the report's Close event:
DoCmd.Close acForm, "ChooseCounty"
When ready to run the report, open the report.
The form will open and wait for the selection of the Company.
Click the command button and then report will run.
When the report closes, it will close the form.
I can persuade the report to trigger the form, but only once - I can't seem to figure out where precisely the 'forms!ChooseCounty!ChooseCounty' needs to go. Perhaps someone can clarify or offer a more elegant way to do this?
I need to set up a large meta-report containing sub-reports on all of the tables - and, using the same drop-down 'choose a county' form, I need to have that choice cascade down through all the subreports. I don't have the faintest idea how to go about this. Suggestions welcome!
~ T
You seem to be asking two questions, the last of which is clear to me, but the first is not. The second one is in regard to how to cascade the filter to the subforms. You can do this in one of two ways:
put the form control reference as criterion in the recordsource of each subreport, OR
create a non-visible control on the report that has as it's controlsource "=Forms!ChooseCounty!ChooseCounty". Name that control "CountyFilter". Then, add CountyFilter to the link properties. If, for instance, you are linking the subreports on ID, you'd have:
LinkMaster: ID;CountyFilter
LinkChild: ID;County
(assuming, of course, that ID is your link field for the child reports, and that "County" is the name of the field in the child subreport).
Now, I'm wondering why you would have the County data not just in the parent record but in the child records -- that makes no sense. If you do have it, then the solution above will work.
If you don't, then I don't understand the question, as the whole idea behind subreports is that they are filtered by the parent record, so if the parent record is a person, and you filter by COUNTY, you're only going to get the child records in the subreport for that person, which by definition are already filtered by COUNTY because the parent has been filtered.
As to the earlier question, you write:
I can persuade the report to trigger
the form, but only once - I can't seem
to figure out where precisely the
'forms!ChooseCounty!ChooseCounty'
needs to go
You have two choices:
hardwire the recordsource of the report to use the form control reference, so the WHERE clause of your report would be "WHERE County=Forms!ChooseCounty!ChooseCounty" (and you should set this as a parameter of type text to insure that it gets processed correctly).
the better meethod is to set the recordsource in the report's OnOpen event.
After you open the form as a dialog, you'd have something like this:
Me.Recordsource = "SELECT * FROM MyTable WHERE County='" _
& Forms!ChooseCounty!ChooseCounty & "'"
And immediately after that line, you can close the form, since it's not needed any longer.
You will likely want an OnNoData event for the case where no records are returned. This is usually something simple like:
MsgBox "No records found!"
DoCmd.Close acReport, Me.Name
I hope this answers your questions, but if not, I'm happy to offer more explanation.
Code in Form onLoad:
country_combo.RowSourceType = "Value List"
Code in a reset function:
Dim lListIndex As Long
With Me.country_combo
For lListIndex = .ListCount - 1 To 0 Step -1
.RemoveItem (lListIndex)
Next lListIndex<br/>
End With
Code to populate country combo:
*For n = 1 To numCountries*
*countryCombo.AddItem (countryRS.Fields("countryName"))*
*countryRS.MoveNext*
*Next n*
I'm having a problem that occurs AFTER the code to populate the country combobox runs. The values are there as I can run Debug.Print(countryCombo.Value) and it prints out the name of the selected country, but I can't see the values in the combobox at all. They're invisible, and as far as I know there is no visiblity property for specific items, unless I'm completely mistaken.
comboBoxError.png http://img110.imageshack.us/my.php?image=comboboxerror.png
I think you should probably use Access's GUI tools to do what you're looking for. In design mode, click on the field you are trying to populate, then click the "lookup" tab. You can then specify a table to populate the field with and your forms should automaticly update as well.
I've also seen what you describe here - as far as I can tell, it's a bug within Access (I was using 2007) that only occurs when you programatically mess with the contents of a combo box. It does not happen every time. The issue corrects itself if you highlight the text that is in the combo box.
I am experiencing a similar issue with Access 2003. Based on the selection of one combo box, the row source of a listbox is set to an SQL string Basically a SELECT DISTINCT [MyField_Selected] FROM MyTable. For some fields the values are visible in the list box and others it is not. The values are there however as I can access them via code. To make it more interesting it works fine in Access 2007.
Just found the resolution on another forum. Check the format property of the field(s) in question on the table. In my case, when Access 2007 created the table, it put an # format in there. I removed that and all works great!