By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,660 Members | 1,953 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,660 IT Pros & Developers. It's quick & easy.

ColumnHistory() generating display error

P: 3
Source: 2007 Call Tracker template DB. After generating a few records and putting in some comment data, I wanted to add a policy reference to each call. I added a policy table with two fields; pid, pName. I added a field to the Calls table called policy and set a one-to-many relationship with The policy table is populated. Before I add policy.pName to the Call Details form, I can see comment history. After adding the field, the comment area generates #Error. I didn't do anything to the comments field, so I don't understand why it's throwing an error. help me understand. thanks!
Feb 20 '17 #1
Share this Question
Share on Google+
3 Replies

P: 3
So digging around the interweb for the columnhistory syntax, there were a few comments about having to replace the [RecordSource] alias with the actual table name. Making this change works to correct the history error. However, I am still not clear on why the introduction of the new table's field on the form generates the error. I would be interested in the explanation, if anybody can provide it.
Feb 23 '17 #2

Expert 100+
P: 1,107
I don't have a copy of the Call Tracker Template Database, so I can only go from what you have supplied. I would guess the reason using the Table Name as the RecordSource seems to work is that it returns all the fields in the Table, compared to what was there before, which I would guess was a Query which was returning only specific fields.

What concerns me most is that now that you have changed the RecordSource to the Table, if the previous RecordSource was bringing in a field that is not in the Table, or it was calculating a field, you may have some new problems with missing fields on your Form.
Feb 23 '17 #3

P: 3
no. I didn't change the recordsource property. I changed the field query all together. I think, because the recordsource function is a form property, it assumes the table/query/formSQLexpression is recordsource for everything in the form. In this case, I am adding a form selection box from a different table which isn't part of the form.recordsource property. Referencing calls.comments directly removes the dependency on the funciton property.
Feb 23 '17 #4

Post your reply

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