Search results

You might have a look at this thread. It is a bit dated, and not completely specific to your situation, but it does cover working with combo boxes in an Access web form, including how to pass data from the combo box to other controls, so it may provide some helpful information. Includes a sample...

You are returning a currency data type from the table. Why are you trying to use a Date format on that value?

Thanks for chiming in MarkK. I am always interested in alternative views on ways to solve problems with code. I have used querydefs a lot, but not in the way you have here, so that's another method I can keep in mind for future reference. I appreciate the input.

This post is a few days old, so you may have already resolved the issue, but if not just check the Benefits field for null before you create the array; With rs .MoveFirst Do While Not .EOF If Not IsNull(!Benefits) Then MyArray = Split(!Benefits, ", ") For i = 0 To UBound(MyArray)...

You have the table name incorrect in your DLookup. You have tbDepositInformation, should be tblDepositInformation

From the new db, go to External Data / Access. Select Import tables, queries...., browse to the location of the older db, then import the updated reports.

You might try looking here. The page is rather dated, but you may still find a few helpful ideas there. Keep in mind that if someone is determined and has a bit of knowledge they may still find a way to get around whatever you try.

You can't reference an unbound control (in this case Text128) when performing a calculation in the footer. You need to Sum the original calculation. For example, if the Control Source in Text128 is =[Expenses]+[Labor], then the Control Source in the footer should be; =Sum([Expenses]+[Labor])

What do you mean by this. You are in design view but you can't figure out how they've done it? Or do you mean that you can't get to design view at all? If the latter, why not? Are you using the run time version of Access or something? (you should be able to get to design view of Northwind if you...

Now that's funny right there. Thanks for the laugh Anthony. I guess the long arm of the law finally got him.

Can you post a sample db that duplicates the problem? That doesn't mean the problem will manifest when I open it on my end but it may help eliminate some possibilities

I wouldn't think that using a third part add-in module like that would have any effect on the ability to use standard Access commands. I've never used any of Peter's Access products, so I couldn't really comment on it, other than to say I don't recall ever hearing of anyone having any problems...

So you have 2 different tables with the same (or very similar) fields/data? This is usually an indication of improper design, but perhaps you can elaborate a bit on your situation.

Just tested with Access 2010 - DoCmd.RunCommand acCmdAppMinimize - minimizes the application window (not just the form, the entire application) Are you saying that the above line is only minimizing the form for you?

In MS Access, the purpose of Reports is to create static documents that will be printed. You can certainly view them on screen if you wish, but that's not really what MS had in mind with the Reports object group. On screen view and/or management of data is handled through Forms. The Forms object...

Open the pop up form in Dialog mode. This will suspend code operation in the calling form until the pop up form is closed. Example; DoCmd.OpenForm "frmYourPopup", , , , , acDialog

Hope you're familiar with VBA code, because that's what you will need to accomplish what you want here. You can find some good information on the subject in this thread.

Having fields like Date2, Date3, etc. may be an indication of an incorrect structure. However, to answer your question, your last statement would need to be written like; IIf(Date()=[Date 2] OR Date()=[Date 3];"true";"false") BTW - having spaces in your field names is not good practice.

There are a couple ways you could reference the table directly. You could use DLookup, although, that wouldn't necessarily be the most efficient method if you have a lot of Controls because you would be executing a domain function for each Control with a Tag property value. You could also use...

True. Thanks for correcting my oversight.