Tech Support Guy banner
Status
Not open for further replies.

MS Access Report: layout question

909 views 6 replies 3 participants last post by  Fireflycph 
#1 ·
I have a report with various items of information. I want the Name and category to be grouped into a column. Next the Delivery and Postal Address in the next column. the Phone numbers in the next column and the various email addresses in the final column. This works well, but doesn't look too pretty as the 'growth' of an item in column e.g. adress affects where the items in the columns next to it start. All these are from 1 record. So, is there a way to keep MemName2 and Termcat together, irrespective of the fact that Deladd has taken up 2 lines and not just one (it has grown). I don't need Termcat to start in the same line as postadd, I need it to be below MemName2. Likewise with phone numbers, if the delivery address is across 2 lines there does not need to be a gap before the Fax number. This layout could change, but the peple that were doing it are used to doing things in Word, and don't understand that the time saved by running a report that has incorporated ALL the changes sometimes needs a little compromise....
Rectangle Font Parallel Number Screenshot
 
See less See more
1
#2 ·
Can you provide the report with some dummy data that shows the overlap problem?
I know all about users complaints when you try to move them away from their preferred methods.
Do they use a word Template or just do their own thing?
 
#3 ·
Hi OB
I'm on holiday now, and will only get back to this next year. But the problem is that sometimes the delivery address is long and 'grows' across two lines. when that happens, the Termcat information - which is similar to something like this: Ministerial appointment in terms of section 5.3 of statute (2016-01-12 - 2019-01-11) - this information appears under the name with a line blank or gap. I've actually written another version with the name on the far left of the page, and the other information arranged across the page. The users were used to using a table in word, but for members whose information changed, every occurrence would need to be found and changed. And people make mistakes. This is another example of me dragging my sister section, kicking and whining, into the reality of relational databases. when I found out that this was still being done manually, I had a little hissy-fit. maybe, by the time I return, they will have looked at the alternate layout and realised that just because the original designed or the layout (who retired 5 years ago) was highly respected, doesn't mean that ways to do stuff hasn't improved! anyway, have a Blessed and safe Christmas. I'm spending mine in the pool, my tree is fake - its too bloody hot for the real thing!
 
#4 ·
If I understand you correctly? THe issue is that some fields have more characters than can fit in the Report field and therefore pushes the field underneath down and out of alignment.

I found a way around that once, I'm sure there's many other ways but I don't know them.

What I would do is to create a field in the query for each of the other fields that may contain too long a string. Lets say your "Deladd" field. So in the query i have a field i call "Add_Chk" That filed would be entered as this, without the quotes: Add_Chk:Len([Deladd])

What it does is to count the characters in that field. So if you have too many characters you will create a macro that sets, on the report, the "PostAdd" field to invisible. Meanwhile you have a different field that normally is hidden, we can call that "PostAdd2" THat field you place underneath where the other fields ends. Remembering that it now is x amount of height/width bigger. This field will link to the "PostAdd" on the query. So what happens is that it counts the characters in that particular field. If it's less than your limit? THen nothing happens. The regular Postadd field is visible and Postadd2 is hidden. If it contains enough characters to expand to a second line. THen you hide the Postadd field and makes the postadd2 visible.

You'll have to do that for every field that may move. And also remember to revert back to normal after the record has been processed.

I hope it didn't confuse you. I'm afraid I didn't explain it very well. Maybe, if I'm bored one of these days I'll create a small DB with a single Table, Query and one report that shows how it works. I actually have to remember how I got it to revert back to "normal" after each Report detail had been viewed/printed.
 
#6 ·
Fireflycph, I think you may have understood it OK and your answer may work.
The reason I asked about the Word Doc is that he could send the data to it instead of creating a Report.
Compliments of the season to both of you. (y)
 
#7 ·
OBP,

Maybe? But I'd still really like to see an example of the problem. Because if it moves the data beneath, due to an excess of characters? Well, then moving the data underneath via a macro etc. ill not work. It's already being moved by the "new" size of the "offending" field. Now if he wanted to move both the field underneath and the one next to it., for some kind of uniformity? Well then it'd work.
If you read his original post again he's talking about several fields. May be a mistake on his part? But the only way to make sure would be to actually see a sample, as you previously suggested. Which I happen to second.
 
Status
Not open for further replies.
You have insufficient privileges to reply here.
Top