Replies

You can let the “Print” button run code or a macro that runs based on conditions. Check each option button, and if true print the applicable report. Only options checked will generate a report.

For two copies of a report try this:
DoCmd.SelectObject acReport, “nameof report”, True
DoCmd.PrintOut , , , , 2
Can you give some more info about the options?

Use the switchboard manager to create a second switchboard named Reports Menu. Edit the Main switchboard so that one of the buttons opens this new switchboard.

I have some mail merge letters (Word docs) that are linked through Access, which contains linked tables (ODBC). The actual tables exist on an IBM mainframe. When I open any of these documents, Access also opens, and I get a logon dialogue box for userid and password. Are you required to log on in order to view the results of your query? Are you trying to open the Access query as your mail merge datasource, or are you trying to open the tables through ODBC? In other words, in Word, are you choosing your Access mdb file as the datasource?

Check this MS knowledge base page:http://support.microsoft.com/support/kb/ar…s/Q224/0/56.ASP It covers many possible causes for what you describe, plus there is a download from Microsoft that will give you more details for many Office2000 error messages(Look for “Customizable Alerts” on the above link).

Edited by Charlotte to activate link

It does sound like you’ll need to create the relationships again. As far as the queries showing a relationship, Access will attempt to automatically create links between tables in a query with identical key fields(i.e. Order_Idx in more than one table). This could explain why some of your queries show the tables as linked.

If these “separate” databases are both Access, and contain the same fields(which you said they do), then you can append one to the other and then export the appended table to your sql server(see Access help under the word “server”, for step by step instructions.) Then once you have a table on the server, you could link to it in an Access database if that is what you require. You need the appropriate ODBC driver and probably a userid and password, if the sql server has security set up(which it should).

Seems like you could do a count on all records, but in criteria use this: “[Datestarted]<[Other Date field]". Maybe I'm misunderstanding your question. Can you provide a little more info?

I agree with Francois. And just for info, the split network database you described, is a front end/back end. The actual tables are in the back end. The front end is linked to the back end tables, and is normally what a user opens. I would forget the C drive (unless you just want to place multiple copies of the front end on each user’s desktop). Of course then you have multiple copies to maintain (or replicate and synchronize). If there aren’t too many users, and the front end does not contain any tables (other than linked), you can make changes to one copy of the front end, if necessary, and then simply replace each user’s copy with your new front end. Warning: if your users are allowed to create/change queries, forms, and/or reports, then they really do need their own copy of the front end. I apologize if I’m straying from the original post.

Are you saying that you want a form residing in a database on the network to link to the table residing on your C drive? Usually people don’t have access to other peoples hard drives, so the form would only work for you. Anyway, you can import (as a link) the C drive table into the networked database, but if this data is only for you, you could instead, import the form from the network into the database on your C drive. Have you considered having a front end database on your C drive, containing the queries and forms that you need; and just link to the tables in the database that resides on the network?

Try this: (Test with a copy) Remove the linked tables in the front end. Then add them all back again. When you add them it will ask for the password, but from then on, the front end won’t ask for the password, and you won’t get the invalid password message.

You can have the log-in form open as a pop-up, which will cause it to remain on top until the user logs in and clicks okay. I have another idea you might want to try: Why not get rid of the option group, but only have the user log-in once? When they log-in and click okay, pass some value from the log-in form to a menu form. The menu form can contain command buttons to your various forms. Code behind the buttons will open the appropriate form using the log-in value to determine which records the user may view. Let the menu form remain open, so that whenever a form is closed, the user again sees the menu and can choose another form or close the database.

What application do the 4 files come from? If they come from 4 users who are simply using a copy of your “master” database, then Charlotte is correct about replication. If you don’t like that answer, how about sharing the database with the users or splitting your database and giving the users their own “front ends” pointing to your “back end”. Unless there is some reason (security?) to restrict access to all files in your table, just let the users update the data directly. If you’re worried about the master database, just be sure it’s backed up frequently.

Use “Like” before your [Enter Number] statement.

Since you say the spreadsheets simulate a database, I am guessing you mean they deal with related data, or very similar information. If this is the case then you probably want to end up with one Access file(with multiple reports) instead of 152 seperate Excel files, which is a nightmare to maintain. Check the Access help on importing Excel files. If there is some commanality between the spreadsheets, you can design a new Access database with a table or tables that will contain the data from your spreadsheets. Data that is common to multiple spreadsheets, such as names, ssn numbers, etc…, should end up in only one Access table. One more suggestion: If many of the spreadsheets are almost identical(many users design a spreadsheet for every little difference they can think of), you should be able to design a few reports in Access to replace a large number of similar Excel spreadsheets. I’m just mentioning this because I worked on a project in which users had created over 200 related spreadsheets, and they wanted me to maintain these files, and to even create more spreadsheets for them. Instead I created one Access database with only a handful of reports, that varied mostly by one or two parameters.