Search results

Rather than having multiple image controls in the parent form you could have a single image control in a continuous forms view subform. This would enable you to scroll the images independently of the parent form. The attached little demo file illustrates this. In the demo each image path is...

1. The Cleared column is not necessary. In the operational database I used as a basis for the simplified file I posted current account statements can be reconciled by comparing the statement with the rows from the table WHERE Cleared = TRUE. 2. A dialogue form for selecting an account number...

The key is being able to determine which of each set of duplicated records was the latest edited. If, for instance, the table includes a DateTimeStamp column whose value is updated with the current date/time when a record is edited, you could then merge the three tables into a single one by...

In situations like this I'd usually output a report to a PDF file.

The attached little demo file illustrates three methods of forcing at least one row to be inserted into a referencing table when a row is inserted into a referenced table. 1. A conventional bound form and subform is used. As it is necessary fro a new row inserted via the parent form to be...

To create an address book report you will need to create a parent report, and two subreports, one for adults, the other for children. Create the parent report with the Households table as its RecordSource property. Order the report by HouseholdName . Place the relevant controls to return the...

The US short date format is not a standard per se. Date literals can be any internationally unambiguous format, as well as mm/dd/yyyy. The ISO standard is YYYY-MM-DD. It would have made sense if this had been made the only acceptable format for date literals.

It sounds like your problem stems from a fault in the relationships between the underlying tables. The model for an Orders or similar database would include tables like those in the image below: The relationship type between Orders and Products is many-to-many, i.e. each order can include...

When I was young one of our officers had been a signaller in the Second World War. I recall him telling us that that was the solution adopted by the British and American forces in signals traffic to avoid misinterpretations of dates. I always use the ISO standard of YYYY-MM-DD for date literals.

I'm afraid that's not possible. Replicating the basic functionality of my demo database is a simple matter, however: Firstly let's assume for now that the database is for one account only. It can easily be adapted to cater for multiple accounts later if necessary. Start by creating a table...

Using multiple domain aggregation functions is a very unusual and inefficient way to build a report like this. Normally the data from the base tables would be aggregated in a query. The following is a simple example using Northwind Developers Edition tables as an example. Firstly the relevant...

That assumes the previous values are incremental. Even this cannot be guaranteed with absolute certainty. I'd add a DateTimeStamp column to the table and use that.

In that context, with the form at record 20, the DLookup function will return Null, which the NZ function will replace with the date before the date in the current row, so the expression as a whole will evaluate to False, regardless of the value of the previous date in record 17.

What happens if you drop the variable and use the following? If MsgBox("Print Customer Receipt?", vbYesNo + vbDefaultButton2) = vbYes Then DoCmd.OpenReport "rptPrintCustomerReceipt", WhereCondition:="[ContractNo] = " & Me.ContractNo End If

As theDBguy points out, an autonumber column is unreliable for anything other than ensuring distinct values. To ensure an unboken sequence you can compute the value when a row is inserted into a table. The attached little demo file illustrates this. Alternatively you can add a DateTimeStamp...

The vbYes constant is an integer data type. Its actual value is 6.

In the file attached to my last reply I'd omitted to amend the form's query so that the DSum function call was restricted to the the currently selected account. I've corrected this and attach the amended file to this post. I've included a couple of dummy accounts, one with a credit...

For a binary relationship type like this you'll probably need two separate interfaces, one in which a Candidates parent form contains a subform based on the VacancyCandidate table which models the relationship type, the other in which a Vacancies parent form similarly contains a subform based on...

You might find the attached file helpful. It contains a simplified version of the original form whose RecordSource query I posted earlier. I've amended the query slightly so that it references an unbound text box control in the form header as a parameter to restrict the rows returned to an...

To record transactions in one or more current accounts you'd just need the one table, whose definition is as in the following image: Be sure to set the DefaultValue property of the Credit and Debit columns to 0. You'd then create a form whose RecordSource property is the name of the query...