[MS_AccessPros] Re: Type mismatch error running reports with conditionally formatted fields

 

Bill,

Yes I did put the report name and file path in quotes.  After digging into the matter further, I restored the database from an older copy backed up and week, and obtained some new test orders to try.  I think I the problem may boil down to just two reports (which may not be in active use anymore), plus the fact that some of the test data I was using was flawed (invalid order range).  Therefore, I've decided to focus back on my original problem of the primary and alternate barcode locations using a new test database.  

With the new test database and keeping in mind the original, I've heard that using IIf statements might be a viable alternative to conditional formatting.  What would be your recommendation, Bill?

---In MS_Access_Professionals@yahoogroups.com, <wrmosca@...> wrote :

Michael 

Did you put the report name and file path in quotes? It should look like this:

saveastext acReport,"rptOrders","U:\_HOLD\rptOrders"

Compacting the front end sure can't hurt.

-Bill

---In MS_Access_Professionals@yahoogroups.com, <mbentfeld@...> wrote :

Bill,

 

Removing the barcode doesn't seem to make a difference now, at least not the in the non-single-order options.  I tried the saving the report as text as you suggested (substituting my own name for the report and the file path for "myReportName" and "fullFilePath", but I get the following error:

 

"Compile Error:

Expected:  end of statement."

 

Using the statement literally made no difference.  Would a Compact & Repair of the front end help?

 

Thanks again,

Michael

---In MS_Access_Professionals@yahoogroups.com, <wrmosca@...> wrote :

Michael

Does it work if you remove the barcode stuff? Maybe that addition corrupted the report. You could try saving the report as text, deleting the existing report and then loading the report from text back into the database. Sometimes that clears up object corruption.

Example: type in Immediate window:

SaveAsText, acreport, "myReportName", "fullFilePath"

LoadFromText acreport, "myReportName", "fullFilePath"

Bill

---In MS_Access_Professionals@yahoogroups.com, <mbentfeld@...> wrote :

Hi Bill,

Sorry I didn't mention earlier, but that's part of the problem.  I've used a test range of two consecutive orders, and both have images.  I've used the "print single order" option and can print each order individually and see the images.  There is an expression in the query associated with the report that looks for in field in one of the SQL tables which denotes the path the image file on a server (the same server as the front end db).  That's what the [DWG] on the right side of the expression on the second screenshot refers to.  I thought that was a bound control but maybe I'm wrong.  This report worked fine before the proposed bar code changes, and even after removing the "alternate" bar code, it still throws that error (except on the previously mentioned single order option).

Thanks again,

Michael

Hi Bill,

 

Sorry I didn't mention earlier, but that's part of the problem.  I've used a test range of two consecutive orders, and both have images.  I've used the "print single order" option and can print each order individually and see the images.  There is an expression in the query associated with the report that looks for in field in one of the SQL tables which denotes the path the image file on a server (the same server as the front end db).  That's what the [DWG] on the right side of the expression on the second screenshot refers to.  I thought that was a bound control but maybe I'm wrong.  This report worked fine before the proposed bar code changes, and even after removing the "alternate" bar code, it still throws that error (except on the previously mentioned single order option).

 

Thanks again,

Michael

Michael

 

When your code breaks are you checking that there is a value in DWG. Can you create a testing report with a that record and see the image?

 

I imagine there is a reason why you are assigning a picture on the fly, but why not use a bound control for that?

 

Regards,

Bill Mosca, Founder - MS_Access_Professionals

http://www.thatlldoit.com

Microsoft Office Access MVP

http://mvp.microsoft.com/en-us/mvp/Bill%20Mosca-35852

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

 

---In MS_Access_Professionals@yahoogroups.com, <mbentfeld@...> wrote :

Hello all,

 

I have a database consisting of an Access 2003 front end with a SQL 2008 back end (actually our ERP database), used to print factory production orders.  The database form allows users to print single orders or a range of orders based on a planner code, a simple numerical range, or a combination of these.  

 

Recently, I have modified the reports to print a bar code to allow orders to be received using a scanner tool.  Per user requests, I am modifying the orders again to allow the bar code to appear in an alternate location for orders with a certain commodity or flow code which should not be received immediately.  To accomplish this, I decided to print the bar code field twice, and use conditional formatting on both fields.  Here's the criterion expression I'm using for the conditional formatting:

 

Expression is [COMCDE_01] like "*Z*"

 

In the primary location, the conditional formatting is set so that the font color changes from black to white when this expression is triggered.  In the alternate location, I use the same expression, but have the colors reversed.

 

When I use this for the report with single orders, it works correctly.  However, when I use this formatting in other reports with the other selection criteria mentioned in the beginning, I get a "Run-time error 13 - type mismatch."  When I look at the vb debugger, the error indicates a problem with a image control used on the reports (I will upload a Word document with screenshots). In the past, has indicated an order for a part that is  missing a bitmap drawing, but none of the parts in my range of test orders is missing a drawing.  I wonder what could be causing this.

I also have PDF samples of what the two bar code variations should look like if anyone thinks it might help.

 

Thanks in advance,

Michael

__._,_.___

---

Posted by: mbentfeld@yahoo.com

---

Reply via web post

•

Reply to sender

•

Reply to group

•

Start a New Topic

•

Messages in this topic (7)

Visit Your Group

• New Members 1

• Privacy • Unsubscribe • Terms of Use

.

__,_._,___