Does anyone have any experience of creating a report that will print labels that are on a roll?
I can see plenty of examples for a sheet of labels, but nothing with any great detail regarding a roll.
Would the best method be to set the report page up to have 1 column and then adjust the size of the page to be the size of the label?
There will be different info on each label, and a varying number of labels per print.
So basically set up the report to mirror the label size and then repeat pages depending on how many labels need printing?
You should just be able to set your report to have the same page size as your label then design the report as normal.
As for producing multiple labels, you can either
have a single dataset containing all the info you need for all labels and group by whatever makes each label unique (e.g. a label number). Then add a page break on the row group property to put a break between each, or ..
you could create a subreport that just handles a single label and then have a master report that with a table control with a single 'cell' and the subreport inside that cell. You would then pass the parameters to the subreport from the main dataset. I think you've seen a similar answer I posted about printing sheets of labels, if you follow that then it should get you most of the way there.
Option 1 is probably the simplest method...
Step-by-Step for option 1
In this example I've used the Microsoft sample database WideWorldImporters, just so I could get some names and addresses.
Step 1: Write your query to get your data. In my example I used the following..
SELECT top 10 o.OrderID, c.CustomerName, c.DeliveryAddressLine1, c.DeliveryAddressLine2, cty.CityName, c.DeliveryPostalCode
FROM [Sales].[Orders] o
JOIN Sales.Customers c on o.CustomerID = c.CustomerID
JOIN Application.Cities cty on c.DeliveryCityID = cty.CityID
ORDER BY OrderID
This just gives me the order number, company name and address.
Step 2: Create a new report. I'm using Visual Studio but the process is almost identical in Report Builder if you use that.
Create a new, blank report
Add a datasource and dataset containing your query from step 1
Select the 'body' and set the size property to your label size. I used 100mm, 40mm
Select the 'report' and set the PageSize property to the same values as above and the margins to 0
Step 3: Add a table to contain the data
Add the new table
Delete the header row
Delete the last column (I have a two column label in my example but obviously up to you)
Select the table (tablix) using the grey table handle (top left of the table) and then set the dataset property to the name of the dataset you created earlier
Add enough rows to contain all your data, in my case 6 in total
In the RowGroups panel under the main report design, right-click the details rowgroup and choose Add Group => Parent Group. Select OrderID as the field to group on and click OK
Remove the newly added column and if prompted choose 'remove column only'
Right-Click the (OrderID) Row group and go to Group properties, click Page Break and choose 'between'
Set each row to contain your data until you end up with something like....
Clean up the formatting and that should be it. One label per page and each page set to your label size.
You may need to adjust the layout slightly to adjust for margins etc but this should give you a good start.
Please help me with the following topic.
I'm having a hard time inserting a form in which i need to select from a drop down list the name of the project and below to display the data from the ProdFinit column.
I've tried using combo but i'm new to Access and i thing i'm missing something.
Thank you for your help!
You're on the right path using a combobox. Look at the format tab on the design properties for your combobox. Here I have a form where the user inputs the zip code, but I also want the user to identify the city and state at the same time. My column count is 3 and I chose how wide to make those columns on the next line down. Beware what column to bind it to on the datatab of the properties box. I find binding it to column 1 is easiest.
ComboBox Properties
Zipcode Combobox
Background: The Record Source for my form is a query ("BigQuery") that just combines several related tables. I am setting up combo boxes to edit fields; the Control Source for these combo boxes is always just a field from BigQuery. One of the fields is UnitType, and another is UnitSubType. There is about 100 distinct entries for UnitSubType, but many of them make no contextual sense when paired with a particular UnitType: If UnitType="Car", then UnitSubType="18 wheeler" makes no sense, and I'd just as soon not give the client the opportunity to make mistakes.
Question, Part A: When the user chooses a value for UnitType on the form, I would like to limit the combo box for UnitSubType to those UnitSubType values already paired with UnitType values in the database. How is this done?
Example: If 1 or more instances of a record containing UnitType="truck" and "UnitSubType="18 wheeler" already exist in the table, then assuming that the user has already selected "truck" in the combo box for UnitType one of the choices presented in the combo box for UnitSubType should be "18 wheeler".
Question, Part B: I would also like for the user to be able to add a new UnitSubType simply by typing it into the combo box: if the user has already selected "truck" in the combo box for UnitType and manually types "flatbed" in the combo box for UnitSubType, then the edited record should have "flatbed" in the UnitSubType and future editing operations should include "flatbed" as a UnitSubType choice whenever the UnitType is "truck". In simpler situations setting "Allow Value List Edits" to "Yes" took care of this, but I want to make sure this functionality is available in the solution provided to Question Part A.
There are similar question threads already in SO, but I am such a noob at Access that I have been unable to extrapolate the answers to fit my need. I am sorry; please, be as specific as possible.
Thank you so much!
Dave
I've arrived at one solution that I wanted to share. Access is difficult to describe, but I will list exceptions to the norm and try to communicate the solution that way.
First (primary) Combo Box for picking the Unit Type:
Name: CBUnitType
ControlSource: UnitType '''A field in the Main Table: MainTbl
Row Source:
SELECT DISTINCT MainTbl.UnitType
FROM MainTbl
ORDER BY MainTbl.UnitType;
Bound Column: 1
Allow Value List Edits: Yes
Locked: No
After Update: [Event Procedure] '''See subroutine: ComboBoxUnitType_AfterUpdate() shown below.
Second (dependent) Combo Box for picking the Unit Sub-Type:
Name: CBUnitSubType
ControlSource: UnitSubType '''A field in the Main Table: MainTbl
Row Source: ComboQueryUnitSubType '''Built by Query Builder, detailed below.
Bound Column: 1
Allow Value List Edits: Yes
Locked: No
Query Builder object: ComboQueryUnitSubType
SELECT DISTINCT [MainTbl].UnitSubType
FROM [MainTbl]
WHERE ((([MainTbl].UnitType)=[Forms]![Unit Editor]![UnitType]))
ORDER BY [MainTbl].UnitSubType;
VBA subroutine created by selecting "[Event Procedure] for the After Update event in combo box "CBUnitType" described above. The VBA subroutine is automatically placed in the Microsoft Office Access Class Objects folder in the VBA environment in a module named: "Form_Unit Editor". The subroutine name is also pre-chosen to be: "ComboBoxUnitType_AfterUpdate()" Almost certainly if you change any of these names the linkages will break horribly. The VBA code in the module is:
Option Compare Database
Option Explicit
Private Sub ComboBoxUnitType_AfterUpdate()
Forms![Unit Editor]![ComboBoxUnitSubType].Requery
Forms![Unit Editor]![ComboBoxUnitSubType].Value = ""
End Sub
So, the effect is this: After the user updates the combo box for Unit Type, the vba routine executes and re-queries the query for the combo box for Unit SubType, and then it arbitrarily takes the .value parameter of the Unit SubType combo box and clears it to the empty string.
I would like to gratefully acknowledge the generous tutorials provided by Blue Claw Database Design. Specifically, the VBA code that re-queries the combo box query was a life-saver, and is detailed in their tutorial on Dependent Drop Down List Box Why the query ComboQueryUnitSubType, specified as the combo box's Row Source, is not re-run automatically by Access every time the combo box is selected by the user is anyone's guess.
I'm sorry for both the long-winded question and answer. I hope to be heading back to some nice, terse code in the near future!
Dave
I am building an SSRS 2005 report using BIDS. My report filters on date. When the selected date returns no data rows the report is blank, just the title is displayed, no table or column heading.
How can I change this to display a message like No data available. or Report is empty.?
You could set the property NoRowsMessage available on the report's table control like this:
Select the Tablix control and press F4 to view the Properties pane.
Find the NoRowsMessage property and set the value to whatever message you'd like.
You can also to format the message using the Font and TextAlign properties.
Here are some examples of what the report will look like under various settings:
Further Reading: Here is a Technet article on how to Set a No Data Message for a Data Region
Avoid NoRowsMessage and build your own conditional empty row
One problem (or feature if that's what you want) with NoRowsMessage is that it'll literally replace the entire table with just a plain old message string.
Which provides a relatively counter-intuitive end user experience in my opinion. Normally when no data is found by a system, we'd like to know something about what data was being looked for and what it would have looked like.
Instead, based off how to keep the structure of the Tablix when there is no data to show, you can do the following:
Insert New Header Row, outside the group and above the details record.
Right click on the side of the new row and Set Row Visibility
Set Visibility to the following expression which will count the rows inside the current Tablix and only set Visibility to True if there is no data.
=CountRows() > 0
Optionally, merge the cells and add your own message or just display an empty row
Here's a comparison of how the various options will render: (pick whichever look you think best fits your data and use case)
Right-click on whatever databound element(s) you are using in the report and there should be a property NoDataMessage There are a host of options there but the Caption is the first element I would look at.
I have searched around, and it seems that this is a limitation in MS Access, so I'm wondering what creative solutions other have found to this puzzle.
If you have a continuous form and you want a field to be a combo box of options that are specific to that row, Access fails to deliver; the combo box row source is only queried once at the beginning of the form, and thus show the wrong options for the rest of the form.
The next step we all try, of course, is to use the onCurrent event to requery the combo box, which does in fact limit the options to the given row. However, at this point, Access goes nuts, and requeries all of the combo boxes, for every row, and the result is often that of disappearing and reappearing options in other rows, depending on whether they have chosen an option that is valid for the current record's row source.
The only solution I have found is to just list all options available, all the time. Any creative answers out there?
Edit Also, I should note that the reason for the combo box is to have a query as a lookup table, the real value needs to be hidden and stored, while the human readable version is displayed... multiple columns in the combo box row source. Thus, changing limit to list doesn't help, because id's that are not in the current row source query won't have a matching human readable part.
In this particular case, continuous forms make a lot of sense, so please don't tell me it's the wrong solution. I'm asking for any creative answers.
I also hate Access, but you must play with the cards you are dealt.
Continuous forms are a wonderful thing in Access, until you run into any sort of complexity as is commonly the case, like in this instance.
Here is what I would do when faced with this situation (and I have implemented similar workarounds before):
Place an UNBOUND combobox on the form. Then place a BOUND textBox for the field you want to edit.
Make sure the combobox is hidden behind (NOT invisible, just hidden) behind the textBox.
In the OnCurrent event fill the listBox with the necessary data. Go ahead and "Limit to list" it too.
In the OnEnter or OnClick event of the textBox give the combobox focus. This will bring the combobox to the forefront. When focus leaves the combobox it will hide itself once more.
In the AfterUpdate event of the combobox set the value of the textbox equal to the value of the combobox.
Depending on your situation there may be some other details to work out, but that should more or less accomplish your goal without adding too much complexity.
use continuous forms .. definitely. In fact you can build entire applications with great and intuitive user interface built on continuous forms. Don't listen to Toast!
Your solution of listing all options available is the correct one. In fact there is no other clean solution. But you are wrong when you say that Acccess goes nuts. On a continuous form, you could see each line as an instance of the detail section, where the combobox is a property common to all instances of the detail section. You can update this property for all instances, but cannot set it for one specific instance. This is why Access MUST display the same data in the combobox for all records!
If you need to accept only record-specific values in this combobox, please use the beforeUpdate event to add a control procedure. In case a new value cannot be accepted, you can cancel data update, bringing back the previous value in the field.
You cannot set the limitToList property to 'No' where the linked data (the one that is stored in the control) is hidden. This is logical: how can the machine accept the input of a new line of data when the linked field (not visible) stays empty?
You could also make the value of the combo box into an uneditable text field and then launch a pop-up/modal window to edit that value. However, if I was doing that, I might be inclined to edit the whole record in one of those windows.
I don't think that Access continuous forms should be condemned at all, but I definitely believe that they should be avoided for EDITING DATA. They work great for lists, and give you substantially more formatting capabilities than a mere listbox (and are much easier to work with, too, though they don't allow multi-select, of course).
If you want to use a continuous form for navigation to records for editing, use a subform displaying the detailed data for editing, and use the PK value from the subform for the link field. This can be done with a continuous form where you place a detail subform in the header or footer, linked on the PK of the table behind the continuous form.
Or, if you are using a continuous form to display child data in a parent form, you can link the detail subform with a reference to the PK in the continuous subform, something like:
[MySubForm].[Form]!MyID
That would be the link master property, and MyID would be the link child property.
We also encounter this a lot in our applicatins. What we have found to be a good solution:
Just show all rows in the comboboxes.
Then, as soon as the user enters the compobox in a specific row, adjust the rowsource (with the filter for that row). When the combobox loses the focus, you can re-set the rowsource to display everything.
I have a simpler way to go than Gilligan. It seems like a lot of work but it really isn't. My solution requires having my continuous form as a subform datasheet. On my subform I have two lookup comboboxes, among other fields, called Equipment and Manufacturer. Both simply hold a Long Integer key in the data source. Manufacturer needs to be filtered by what is selected in Equipment. The only time I filter Manufacturer.RowSource is in the Manufacturer_GotFocus event.
Private Sub Manufacturer_GotFocus()
If Nz(Me.Equipment, 0) > 0 Then
Me.Manufacturer.RowSource = GetMfrSQL() '- gets filtered query based on Equipment
Else
Me.Manufacturer.RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End If
End Sub
In Manufacturer_LostFocus I reset Manufacturer.RowSource to all Manufacturers as well. You need to do this because when you first click in the subform, GotFocus events fire for all controls, including Manufacturer, even though you are not actually updating any fields.
Private Sub Manufacturer_LostFocus()
Me.Manufacturer.RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End Sub
In the Enter event of Manufacturer you have to check if Equipment has been selected, if not set focus to Equipment.
Private Sub Manufacturer_Enter()
If Nz(Me.EquipmentID, 0) = 0 Then
'-- Must select Equipment first, before selecting Manufacturer
Me.Equipment.SetFocus
End If
End Sub
You also need to requery the Manufacturer combobox in Form_Current event (i.e. Me.Manufacturer.Requery), and you should set the Cycle property of this subform to "Current Record".
Seems simple enough, but you're not done yet. You also have to reset Manufacturer.RowSource to all Manufacturers in the SubForm_Exit event in the parent form in case the user goes to the Manufacturer combobox but does not make a selection and clicks somewhere on the parent form. Code sample (in parent form):
Private Sub sFrmEquip_Exit(Cancel As Integer)
Me.sFrmEquip.Controls("Manufacturer").RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End Sub
There is still one piece of this that is not clean. When you click on Manufacturer and have multiple rows in the datasheet grid, Manufacturer field will go blank in other rows (the data underneath the comboboxes is still intact) while you're changing the Manufacturer in the current row. Once you move off this field the text in the other Manufacturer fields will reappear.
This seems to work well.
CBOsfrmTouchpoint8 is a combobox shortened to just the dropdown square.
CBOsfrmTouchpoint14 is a textbox that makes up the rest of the space.
Never say never:
Private Sub CBOsfrmTouchpoint8_Enter()
If Me.CBOsfrmTouchpoint8.Tag = "Yes" Then
CBOsfrmTouchpoint14.SetFocus
Me.CBOsfrmTouchpoint8.Tag = "No"
Exit Sub
End If
Me.CBOsfrmTouchpoint8.Tag = "No"
Me.CBOsfrmTouchpoint8.RowSource = "XXX"
Me.CBOsfrmTouchpoint8.Requery
Me.CBOsfrmTouchpoint8.SetFocus
End Sub
Private Sub CBOsfrmTouchpoint8_GotFocus()
Me.CBOsfrmTouchpoint14.Width = 0
Me.CBOsfrmTouchpoint8.Width = 3420
Me.CBOsfrmTouchpoint8.Left = 8580
Me.CBOsfrmTouchpoint8.Dropdown
End Sub
Private Sub CBOsfrmTouchpoint8_LostFocus()
Me.CBOsfrmTouchpoint8.RowSource = "XXX"
Me.CBOsfrmTouchpoint8.Requery
End Sub
Private Sub CBOsfrmTouchpoint8_Exit(Cancel As Integer)
Me.CBOsfrmTouchpoint14.Width = 3180
Me.CBOsfrmTouchpoint8.Width = 240
Me.CBOsfrmTouchpoint8.Left = 11760
Me.CBOsfrmTouchpoint8.Tag = "Yes"
End Sub
What if you turn off the "Limit To List" option, and do some validation before update to confirm that what the user might have typed in matches something in the list that you presented them?
Better...
Set you combo box Control Source to a column on the query where the values from your combo box will be stored.
For Me I think the best way and easiest way is to create a temporary table that has all your bound fields plus an extra field that is a yeas/no field.
then you will use this table as the data source for the continuous for. You can use onLoad to fill the temporary table with the data you want.
I think it is easy after that to loop for the choices, just a small loop to read the yeas/no field form the temporary table.
I hope this will help
Use OnEnter event to populate the combo box, don't use a fixed rowsource.
I've just done similar. My solution was to use a fixed row source bound to a query. The query's WHERE clauses reference the form's control i.e. Client=Forms!frmMain!ClientTextBox. This alone will fill the combo boxes with the first row's data. The trick then is to set an 'On Enter' event which simply does a re-query on the combo box e.g. ComboBox1.Requery, this will re-query that combo box alone and will only drag in the data related to that record row.
Hope that works for you too!
Disclaimer: I hate Access with a passion.
Don't use continuous forms. They're a red herring for what you want to accomplish. Continuous forms is the same form repeated over and over with different data. It is already a kludge of Access's normal mode of operation as you can't have the same form opened multiple times. The behavior you are seeing is "as designed" in Access. Each of those ComboBox controls is actually the same control. You cannot affect one without affecting the others.
Basically, what you have done here is run into the area where Access is no longer suitable for your project (but cannot ditch because it represents a large amount of work already).
What seems to be the most likely course of action here is to fake it really well. Run a query against the data and then create the form elements programmatically based on the results. This is a fair amount of work as you will be duplicating a good bit of Access's data handling functionality yourself.
Reply to Edit:
But as they are, continuous forms cannot accomplish what you want. That's why I suggested faking out your own continuous forms, because continuous forms have real limitations in what they can do. Don't get so stuck on a particular implementation that you can't let go of it when it ceases to work.