Search results

I have someone with 2013 verifying this issue now...I have been expecting it to be something I fundamentally don't know about but it isn't the case so far.

Hi, Well, I set a breakpoint in the format code, and when it paused I looked at the name it was seeing for the person in the record. It was actually showing the name from another report - the third instead of the first which it immediately stopped on. So, when I print multiple reports...

Hi, Well, I set a breakpoint in the format code, and when it paused I looked at the name it was seeing for the person in the record. It was actually showing the name from another report - the third instead of the first which it immediately stopped on. So, when I print multiple reports, the...

>>>maybe you are running the format event not in the detail section, but in one of the other sections, so it is not checking every record. Most definately not. I am tossing around installing a hotfix I found where it states that the filter doesn't run properly in MS Access 2010 SP1. If you...

The code in reports runs ONLY when the report is opened in print preview or normal view which is "send directly to printer". Report view and layout view do not run the code. Quote:>>>>I've only ever ran it this way. I also tried printing it. - shows the same data that is on the preview.

Well, I can't understand why you are telling me the where clause is wrong - it results in the correct records. Its just the form event that is failing - when you scroll thru them. Doesn't a msgbox pop up with the where contents? It's correct, right? In terms of the matching of the data types...

I read about the retreat yesterday when attempting to find a solution. I also read that the format event is supposed to fire for each record, but even as it does - it seems to only point to a single record when running the logic. In other words, the if logic runs on the fields based on the...

I guess I sent you one with the data types back to where they were. I did test with exact same types - no diff. Also a bit confused as to how my where could be invalid when the data is actually presented with records resulting from the where - indicating it is valid.

I have a post already here:http://www.access-programmers.co.uk/forums/showthread.php?t=252010&highlight=run+on+format+event+for+each+record+for+report Which has a very simplified example of what I am trying to do. Essentially it seems like the format event fires only once with a docmd that has...

New db attached - simplified no sub report - still fails UPDATE and NEW INFO: I removed the sub report and put a small section of it in the details of the main report. In doing so, the record source query changed appropriately. I placed the logic corresponding to that part into the on...

UPDATE: I've removed all logic from the format event code and am just spitting out the data directly. It works. It seems that any logic in the format event causes the relationship between the data in the main and sub report to fail.

UPDATE: I had been getting a value from the calling form via the Form! method. I hard set this in the form event code. I also commented out all but one of the section checks (the top if / endif block) to make the sub report only run that and make it less intensive. No change, except it...

Made them both the same, it acts exactly as it did prior. Nice call, tho. t

Thanks - been going a hundred mph on this project, and this data originated from another source. I REALLY appreciate it. Also, I kind of new to db work...I am sure it shows.

As far as I can see, its all set up properly. I will try and attach the db here if you are interested in looking...the zip was posted to another forum, hence the text in the word doc addressing someone else. Thanks for your reply tho, very much. Thanks, t

If I print a single report its good every time. If I print a batch with a where in the docmd, it prints the correct records - but the logic begins to fail after the first report on the sub reports. The random data that does print on the sub report is accurate. If I go into debug mode, as it...

I must have been drinking too much coffee. I removed the post....

I am sure this is misunderstood, as I think I misunderstood the response in the first place. At any rate, I was able to get a solution to this issue overall by referencing a single sub report in the details section. It was actually quite straightforward. Sorry for the WOB. Troy

>>>>When placing controls on the form, always make them one line tall (or shorter) and set their can shrink/can grow properties to yes. Do you mean to do this in the designer, so as to maximize the available real estate in the view? I guess lay it all out then reset the heights afterward...

Noob has removed spurious post and put it in the right spot!