Is there a reason for using a Totals query in this case? Other than the
one
First aggregate function in the SELECT clause, I see no use of any
aggregate
functions that would necessitate the Totals query design. It appears to
me
that this query should work for you:
SELECT SYSADM_WORK_ORDER.BASE_ID, SYSADM_WORK_ORDER.PART_ID,
SYSADM_PART.DESCRIPTION, SYSADM_WORK_ORDER.DESIRED_RLS_DATE,
SYSADM_WORK_ORDER.DESIRED_WANT_DATE, SYSADM_WORK_ORDER.SCHED_START_DATE,
SYSADM_WORK_ORDER.SCHED_FINISH_DATE, SYSADM_WORK_ORDER.DESIRED_QTY,
SYSADM_OPERATION.RESOURCE_ID, CDbl(SYSADM_OPERATION!SEQUENCE_NO) AS
SEQUENCE,
SYSADM_OPERATION.CALC_END_QTY, SYSADM_OPERATION.CALC_START_QTY,
SYSADM_OPERATION.SETUP_HRS, SYSADM_OPERATION.RUN_HRS,
SYSADM_OPERATION_RESOURCE.RESOURCE_ID, CDbl([PIECE_NO]) AS PIECE,
SYSADM_REQUIREMENT.PART_ID, SYSADM_PART_1.DESCRIPTION,
SYSADM_REQUIREMENT.REQUIRED_DATE, SYSADM_PART_1.STOCK_UM,
SYSADM_REQUIREMENT.CALC_QTY, SYSADM_REQUIREMENT.ISSUED_QTY,
SYSADM_PART_1.BACKFLUSH_LOC_ID, SYSADM_OPERATION.SCHED_START_DATE,
SYSADM_OPERATION.SCHED_FINISH_DATE, RAW2STR(SYSADM_WORKORDER_BINARY!BITS)
AS
[Workorder Bits], SYSADM_PART_1.BACKFLUSH_WHS_ID,
SYSADM_REQUIREMENT.QTY_PER,
(RAW2STR(SYSADM_OPERATION_BINARY!BITS)) AS [Operation Bits]
FROM ((((((SYSADM_WORK_ORDER INNER JOIN SYSADM_OPERATION ON
(SYSADM_WORK_ORDER.SUB_ID = SYSADM_OPERATION.WORKORDER_SUB_ID) AND
(SYSADM_WORK_ORDER.SPLIT_ID = SYSADM_OPERATION.WORKORDER_SPLIT_ID) AND
(SYSADM_WORK_ORDER.LOT_ID = SYSADM_OPERATION.WORKORDER_LOT_ID) AND
(SYSADM_WORK_ORDER.BASE_ID = SYSADM_OPERATION.WORKORDER_BASE_ID) AND
(SYSADM_WORK_ORDER.TYPE = SYSADM_OPERATION.WORKORDER_TYPE)) LEFT JOIN
SYSADM_REQUIREMENT ON (SYSADM_OPERATION.SEQUENCE_NO =
SYSADM_REQUIREMENT.OPERATION_SEQ_NO) AND
(SYSADM_OPERATION.WORKORDER_SUB_ID
=
SYSADM_REQUIREMENT.WORKORDER_SUB_ID) AND
(SYSADM_OPERATION.WORKORDER_SPLIT_ID
= SYSADM_REQUIREMENT.WORKORDER_SPLIT_ID) AND
(SYSADM_OPERATION.WORKORDER_LOT_ID = SYSADM_REQUIREMENT.WORKORDER_LOT_ID)
AND
(SYSADM_OPERATION.WORKORDER_BASE_ID =
SYSADM_REQUIREMENT.WORKORDER_BASE_ID)
AND (SYSADM_OPERATION.WORKORDER_TYPE =
SYSADM_REQUIREMENT.WORKORDER_TYPE))
LEFT JOIN SYSADM_PART AS SYSADM_PART_1 ON SYSADM_REQUIREMENT.PART_ID =
SYSADM_PART_1.ID) LEFT JOIN SYSADM_OPERATION_RESOURCE ON
(SYSADM_OPERATION.SEQUENCE_NO = SYSADM_OPERATION_RESOURCE.SEQUENCE_NO)
AND
(SYSADM_OPERATION.WORKORDER_SUB_ID =
SYSADM_OPERATION_RESOURCE.WORKORDER_SUB_ID) AND
(SYSADM_OPERATION.WORKORDER_SPLIT_ID =
SYSADM_OPERATION_RESOURCE.WORKORDER_SPLIT_ID) AND
(SYSADM_OPERATION.WORKORDER_LOT_ID =
SYSADM_OPERATION_RESOURCE.WORKORDER_LOT_ID) AND
(SYSADM_OPERATION.WORKORDER_BASE_ID =
SYSADM_OPERATION_RESOURCE.WORKORDER_BASE_ID) AND
(SYSADM_OPERATION.WORKORDER_TYPE =
SYSADM_OPERATION_RESOURCE.WORKORDER_TYPE))
LEFT JOIN SYSADM_PART ON SYSADM_WORK_ORDER.PART_ID = SYSADM_PART.ID) LEFT
JOIN SYSADM_WORKORDER_BINARY ON (SYSADM_WORK_ORDER.TYPE =
SYSADM_WORKORDER_BINARY.WORKORDER_TYPE) AND (SYSADM_WORK_ORDER.BASE_ID =
SYSADM_WORKORDER_BINARY.WORKORDER_BASE_ID) AND (SYSADM_WORK_ORDER.LOT_ID
=
SYSADM_WORKORDER_BINARY.WORKORDER_LOT_ID) AND (SYSADM_WORK_ORDER.SPLIT_ID
=
SYSADM_WORKORDER_BINARY.WORKORDER_SPLIT_ID) AND (SYSADM_WORK_ORDER.SUB_ID
=
SYSADM_WORKORDER_BINARY.WORKORDER_SUB_ID)) LEFT JOIN
SYSADM_OPERATION_BINARY
ON (SYSADM_OPERATION.SEQUENCE_NO = SYSADM_OPERATION_BINARY.SEQUENCE_NO)
AND
(SYSADM_OPERATION.WORKORDER_SUB_ID =
SYSADM_OPERATION_BINARY.WORKORDER_SUB_ID) AND
(SYSADM_OPERATION.WORKORDER_SPLIT_ID =
SYSADM_OPERATION_BINARY.WORKORDER_SPLIT_ID) AND
(SYSADM_OPERATION.WORKORDER_LOT_ID =
SYSADM_OPERATION_BINARY.WORKORDER_LOT_ID) AND
(SYSADM_OPERATION.WORKORDER_BASE_ID =
SYSADM_OPERATION_BINARY.WORKORDER_BASE_ID) AND
(SYSADM_OPERATION.WORKORDER_TYPE =
SYSADM_OPERATION_BINARY.WORKORDER_TYPE)
WHERE (((SYSADM_WORK_ORDER.BASE_ID)=[enter base ID]))
ORDER BY CDbl(SYSADM_OPERATION!SEQUENCE_NO), CDbl([PIECE_NO]);
Otherwise, I don't see anything obvious in the query's SQL that would
lead
to truncation in my experience. Are you sure that the field is being
truncated? perhaps it's just not growing because the textbox control's
Can
Grow property isn't set to Yes and the Group Header section's Can Grow
property isn't set to Yes?
--
Ken Snell
<MS ACCESS MVP>
jeremyj54 said:
Here is the query the Operation Bits is the one im having problems
with.
:
I've just tested a report where I put a textbox bound to a memo field
in
a
report's Group Header section; no truncation noted.
What is the report's RecordSource query? Identify the data types of
the
fields.
--
Ken Snell
<MS ACCESS MVP>
The field is not in the sorting and grouping list for the report.
More information if this helps, this is a converted field from a
linked
oracle table that originally is a long raw field converted to
string.
Like
I said it shows correctly in the detail section, just not in the
group
header.
:
I am guessing that the textbox's ControlSource field is in the
Sorting
&
Grouping list for the report? If yes, ACCESS will truncate the
string
to
255
characters because it must group on that field -- and grouping on a
field
causes ACCESS to limit the string to 255 characters.
--
Ken Snell
<MS ACCESS MVP>
I have an access report that I have placed a text box in one of
the
group
headers and it is only showing 255 charecters. If I place the
same
text
box
in the detail section it shows all charecters. How do I get all
to
show
in
the header, I have got can grow/shrink to yes and it is not in
the
sorting/grouping under view.
