Search results

Just do a search on naming conventions here and you should find some. Like I said I don't use them on fields. But I use them on other objects. I use tbl for regular tables, tlu for lookup tables and tjx for junction tables. I use frm for forms, qry for queries and rpt for reports. On forms and...

I took a look at your database and there are some normalizations issues. You should have a separate table for Addresses and then link to that table from your Transactions, Media and Client tables. Alos you are using prefixes for fields that have no meaning. I generally don't use prefixes for...

Just run an update query matching the PSG

You can link to tables in as many databases as necessary. Any changes made to a linked table are reflected in the database those tables reside in.

To be more specific, its stored as the Value property of the control. The Value property is the default, so using: x = Me.Controlname will set x to the current selection of the combo. You use the Remember Value option for unbound combos where you are selecting a value that can't be bound to...

I disagree with this. As a general rule calculated values should NOT be stored. You can display the results of the calculation anytime you want using the expression. Storing calculated values leads to inaccuracy and denormalization.

First, private messages should only be used for personal correspondence. To post a follow up questions reply in the thread. Second, You have to use your actual control names. I used cboIssueCode as an example. You need to use the actual name of the combobox where you select the Issuecode.

Both tables should have their own PKs. CustomerID should be a FOREIGN Key in tblAnnualService.

First, codefield cannot be a number field since you are including text. Second, I agree with Neil about naming conventions. Third, The MyNumberfield expression only increments THAT field. To displa the WHOLE code you need to include the Date formatting. Please review the full instructions gave you.

First Thanks to Seargeant for catching that error. He offers one solution. I would have chosen to Add Dim strSQL1 As String Then change strSQL1 = "INSERT INTO table (LeaseID, LeaseMonth) " and strSQL = strSQL1 & "VALUES(" & Me.txtLeaseID & ", #" & dteCurrMth & "#);" As do the problem you...

Yes, anyplace you need to use the total of payments you would use the same expression to calculate it. Whether its just for display on a form or report or used in a further calc. In fact, using it in a further calc makes it more imperative not to store it. if you store it you have to make sure...

I'm not trying to be patronizing, but you are mixing apples and oranges. You equate the assignment of a primary key to the prevention of duplicate entries. The two have little to do with each other. I've been helping out on boards likes these for a long time, I've also been designing databases...

Try: Mynumberfield = Nz(DMax("[Mynumberfield]", "tblMytable", "[Mydatefield] = #" & Date() & "#"),0) + 1 Also eliminate the MyDatefield = Date(). The above expression will add 1 to the highest value of MyNumberfield in your table for the current day.

As I said in my last response, you misunderstood where the codes were being entered. I didn't mention indices in my initial response because it didn't apply. But indices are only one of the ways to prevent duplications. Since that wasn't the question, I didn't deal with that issue.

Again I disagree and suggest you do some research on this issue. I'm afraid you do not fully understand the purpose of a PK. As I explained its not the purpose of the autonumber (or a PK) to prevent duplication of data. Its up to the developer to build in verification to prevent that happening...

glad to assist

Agreed, However, if that occurs, the field can be added at that time and existing records filled with the original string.

I strongly disagree here. The sole purpose of an autonumber datatype is to provide a unique identifier to a record. If you aren't going to use it for a PK then it has no value. It is true that using an autonumber doesn't prevent duplicate data. That's the function of your indexes. In the...

Neil's points have merit, but I can see where it may not be practical to store the premium in the payments table. For example, the premium is fixed and annualized. So you would only want to store the premium once. I would agree in that circumstance you would use a Union query to get the balance.

To add to Neil's answer since the prefix is fixed, you don't need to store that. To DISPLAY the full ID you would use: ="AB" & Format([MyDate],"yymmdd") & "-" & [MyNumber]