Summary:
I am trying to determine the easiest way to mask the output of a specific column in a MS-Access Report.
The situation:
I have a table of "contacts" that each must belong to an "organization". The contacts table was populated with legacy data, which did not rigidly enforce the relationship between contacts and organizations. On import, if a contact did not belong to an organization it was assigned to a dummy "legacy" organization (to preserve integrity, and allow us to search for and eventually back fill those values).
My question:
My problem is this - When generating a mailing list report from the contacts table the name of the dummy "legacy" organization populates for those pesky legacy contacts. I need to mask this output in such a way that all the other columns of those rows remain untouched and the organization name column is simply blank. These rows need to be included (not filtered), but if their organization == "Legacy", then on the report the organization name needs to be blank.
My thoughts:
I have contemplated a simple VBA macro to make edits to the report once it loads, but I was wondering if there was a more straight forward mechanism. I know Access allows for input masking, does it have anything similar for outputs?
Thanks,
Chris
Why not base your report on a query?
SELECT ContactID, IIf(Company="Legacy",Null,Company)
FROM Contacts
You can also do something similar in a report control, but ensure you rename the control before you set it to a function.
Related
I currently have a Multi-Value field based on a list of e-mail address, in MS Access 2016. Both the destination table, and the table where the list is pulled, are linked tables. The ComboBox doesn't work for either Queries or Forms when the destination table is a Linked Table. It works for regular Table.
I wish to save multiple e-mail address in this field, without having to use a secondary table (this would be a better design, but would make building forms a complete nightmare, both for me and the users). The inner data storage is a CSV-like format with a ";" delimiter, automatically handled my Access.
To answer obvious questions :
I will not use a separate table as "Good Design" suggests, to not kill UX and database simplicity.
There is no VBA involved at all anywhere in that selection form.
Question : What am I missing, and what can I do to make this work in an MS Access Form with a linked table?
Here it what the selection tool from Access Form looks like :
The solution ended up being :
Unlink the table from the front-end
Re-link it
It seems like any complex field (Multi-Value, Calculated, Attachment) requires a re-linking of the table.
I'm attempting to import a csv file in Microsoft Dynamics 2011. The file is an export of sales data from our website and I'm attempting to create new Account, Contact, Invoice, Order, Invoice Product and Order Product entities using this data. I'm using a multi-entity data map to do this.
When I attempt the import however, creating the invoice fails with the message "The lookup reference could not be resolved." in connection with the currency field. This field is a lookup tied to currency name which in all cases is "US Dollar". This is exactly the same name as the USD currency in our database, but for some reason the lookup refuses to assign it correctly. There are no other currencies in our database with this name.
Can anyone offer me an explanation as to why this is happening and any steps I can take to deal with it? Many thanks.
EDIT: More information about my problem.
It seems that problems occur when I try and perform a multiple entity import with duplicates. All the new entries I'm creating from this import is dependent on other new entries created with the same data. I'm creating accounts, then creating customers to assign to those accounts for example. If said accounts have duplicates already in the system, they are ignored. This is expected. However, when it comes to create the customer assigned to that account, the lookup fails with a "Duplicate lookup reference was found" error. This error occurs when there are more than one things in the database that fit the value I'm using with the lookup.
I'm not 100% sure, but I think it's counting both the account that was ignored and the original account that's already in the system when performing the lookup. Can anyone offer more insight on how I might work around this?
I don't know for sure if this is your issue but my guess it is.
In the import wizard you can select how he resolves your lookups.
i.e: when in your CSV file the column contains the name of the currency you will have to select the name field in your import wizard for the currency field.
In the screen here you can see then country is a lookup and the name of the country is the value of CSV file. It must match the field of the lookup. If I select "created on" It doesnt find the lookup. because no country exists where created on equals "Belgium". So you select the Name field of the lookup and that is how he will check your value in the CSV in the lookup field you defined.
1.Put records for each record type in a separate file.
2.Put records for different owners in a separate file.
3.Ensure that the first line of the file contains column headers and that they match the CRM attribute display names EXACTLY if you would like the import wizard to automatically* map the data. *Automatic mapping is required if you intend to import records that are related to another record (See #6). I HIGHLY RECOMMEND USING AUTOMATIC MAPPING EVEN IF YOU DO NOT DESIRE RELATED RECORDS.
4.Make sure the first column heading is not the name of a record type.
5.Make sure data exists in your source file for all CRM required fields (denoted with a red asterisk on the CRM form).
6.Make sure some data exists for each column. If a column has no data delete the column.
7.If your data should be related to another record (i.e. Adding Contacts to existing Accounts) make sure the column header matched the CRM lookup attribute display name. If you have two different attributes in CRM with the same display name you will receive an error (EX. if you created a custom State picklist value to replace the text version and keep the display name the same "Address 1: State/Province"). Also make sure the company name values will match a corresponding account record (i.e. contacts with a Parent Customer value of Microsoft Corp. will not be added to the CRM Account Microsoft) and that there are no duplicate Accounts in the system as the import will not be able to resolve the proper Parent Customer.
8.If you are importing into a drop-down list, ensure all the values exist within CRM and there are no typographic errors and consistent capitalization in the source file.
EDIT: It seems like indeed there are multiple records in your DB that can fit in that 1 lookup. it's normal that he gives an error on this as he can't resolve the lookup. The CRM doesn't know which record to take.
Also you might want to watch out if you are importing a M-N Relationship. You will have to do a M-N Relationship with code. The standard import wizard cannot handle Many-to-many relationships
I'm trying to make access conditionally only show rows that meet a certain condition, allow me to give you some background info before I proceed :
I've created an Access form and linked it to a test DB on my machine. The particular table I am interested in contains the following (important) rows :
ID , Office, Name, SecurityNumber
The thing is, ID is not unique. There are two Office locations, and each Office has it's own set of unique ID numbers. This means that ID 10 here and there may or may not be the same person. (this data comes out of a legacy security system we're not looking to change yet, so I cannot change it)
But ID -is- unique to each Office.
SO! I created an Access form with TABS! Two tabs, one for each office. What I am trying to achieve now is :
Have the ID/Name/SecurityNumber fields for each tab populate with only rows that match it's particular 'Office' value.
Thank you for reading and thank you for helping! :D
If you want the data for the office locations presented in separate tab page controls, you could use subforms on the pages which differ only in the WHERE clause of the queries used as their record sources. So for the Office1 subform, the query could be:
SELECT ID, Office, [Name], SecurityNumber
FROM YourTable
WHERE Office = 'Office1'
ORDER BY [Name];
Then for Office2, the query would be the same except for the WHERE clause:
WHERE Office = 'Office2'
As I understand your question, that approach would do what you're asking for.
However, that's not really the easy "Access way" to do it. Instead consider a combo box control to allow your users to choose which office they want to view. In the code for the combo's after update event, either modify the SELECT statement used as the form's record source or create a filter expression an apply it.
Also, since you're pulling the form's data from SQL Server, consider whether you want your form to load every record for the selected office location. It may not be much concern if you have only a few to moderate number of rows for each location, but if you'll be dealing with multiple thousands of rows it could be. In general, you should try to avoid pulling copious amounts of data across the wire; pull sparingly instead ... only what you need for the immediate task at hand.
The company I work for have an access database that is linked to a sql server table. The database is on a shared network location so it is used by lots of people in the company (with the annoying problem that only one person can use it at a time).
There are several forms that are used as a front end for the data and on one particular form there are combo boxes that are linked to other tables.
When a report is generated on the form the ID of the combobox is on the form (a GUID) and not the bound item of the combobox.
How can I get the bound items to appear on the form itself? The solution needs to be easy to do or something i can produce that can be regenerated as it's used by non technical people.
In order to make the database usable by many, simply give each user a copy of the front-end.
Forms should almost never be used for reports, the best thing to do is to build a query (the query design window will help) that references each of the relevant tables, for example, if the combobox contained a reference to person type and you might build a query like this for your report:
SELECT a.ID, a.SName, a.MainAddress, c.PersonType
FROM Addresses a
INNER JOIN PersonTypes c ''Or LEFT JOIN if data is missing
ON a.PersonTypeKey = c.PersonTypeKey
If this is not possible, perhaps you could explain in more detail exactly how the report is generated from the form.
I am new to Access and i am in the process of creating a database for some of our users. I have designed a form where the user name, first and last name etc are inputted.
Some of these users work for more than one department which means I need some type of listbox control that allows them to select more than one department when they enter their contact info.
In VB Studios 2005, this control is called a CHECKED LISTBOX. I have looked everywhere in access but cant seem to find it or anything closely similar.
The option of a listbox or combobox is not feasible here as these only allow the user to select one option only when inputting their details. Any help with this is much appreciated.
Use an ordinary list box with the "Multi Select" property set to "Simple".
The user can then click multiple list items, all of which stay selected until they un-select them again.
You may wish to consider a subform, as this will save you the trouble of updating a table with the data from a list box. A subform can use a department-person junction table with person id as the linked child field and master field. A combobox bound to department id will allow the user to select departments.
If you are really set on having checkboxes, Stephen Lebans has a sample database that uses the built-in Access listbox with checkboxes (from one of the Access wizards).
There is another choice:
If you are using Access 2007, you can declare your field as a lookup field accepting multiple values.
When you bind the list box to that field, you will get checkboxes.
It's easy to use them.
You'll also find more information is available from the MS Office website.
However, note:
This is only possible in the new Access 2007 database format and you will not be able to save your database to the older MDB format.
Multiple value fields are not compatible with most other databases, meaning that if you decide one day to upsize to SQL Server, you'll have to redesign your tables to use a junction table as Remou mentioned.
These multi-value fields are difficult to use from VBA: the value they return is in fact another recordset that you must iterate through to get all the values.
Having said that, if you just want something simple and you're not planning on manipulating the database from code, then it can be a practical option, albeit not a very compatible or future-proof one.
I'm not using them, but I think others should be able make their own decision knowing what is available to them.