Can't figure out "Arguments are of the wrong type..."

[jaycast]

Can someone take a look at this code piece and tell me why my report isn't running. I'm using the same report in other places with almost exact properties in each place. My eyes are crossing and I have a headache. PLEASE HELP!

rst274.Open mysql, sql, adOpenKeyset, adLockOptimistic

Set FedExBasicChargeCriteria.DataSource = rst274

With FedExBasicChargeCriteria.Sections("Section1&quot
.Controls("txtSoldTo&quot.DataField = "SoldTo"
.Controls("txtInvNum&quot.DataField = "invnum_xinvbox"
.Controls("txtTrackNum&quot.DataField = "TrackingNum"
.Controls("txtItemID&quot.DataField = "itemid_invdet"
.Controls("txtChargeAmt&quot.DataField = "ChargeAmount"
.Controls("txtShipDate&quot.DataField = "ShipDate_xinvbox"
End With

With FedExBasicChargeCriteria.Sections("Section2&quot
.Controls("lblHeader&quot.Caption = "FedEx Invoice Exclusion Report for 'RES' Charge Codes"
End With

With FedExBasicChargeCriteria
.LeftMargin = (1440 * 0.25)
.RightMargin = (1440 * 0.25)
.TopMargin = 0
.BottomMargin = 0
.Show
End With

Thanks in advance.

 

[tedsmith]

have you dimensioned everything the same way or got your private and public sub statements out of whack?
I like to dimension everything in the startup module and make them public at first and dont dimension in subroutines.

To test
Put the show at the start of the report and normalise it
Put a break at the first line of the sub
Show the code window and report side by side and step thru and see if all the values appear one by one
it might show you what is missing or miss spelt

 

[johnwm]

tedsmith
An alternative (and possibly more generally accepted) method for Dimming variables is to limit the scope of them to as small as possible. All variables should have minimum scope - individual Procedure if possible, Module if necessary and only very rarely program level Public (or Global as it was known)

Most programmers would have the Tools|Options|Editor|Require Variable Declaration option set, which automatically puts the Option Explicit statement at the front of each new module, and goes along way to preventing typing errors in variable names

jaycast
You may need to check the results of the SQL, as it looks as if your query may be adrift

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'People who live in windowed environments shouldn't cast pointers.'

 

[tedsmith]

johnwm
Yes I know that many programmers say this but it slows the program down having to dim variables every time a sub is accessed and makes the system work harder shifting memory about. It can also create small memory leaks if say an interrupt driven sub like an oncom fires while another is in progress.
I make them all dim to the form or module at first then put the rarely used ones in their own procedure later and NEVER use the same variable name twice.
I only use public if the same variable has to be used in a module or other form. I dont like passing variables in the brackets of subs much either as you are dimensioning memory every time you are calling a sub.

 

[strongm]

>it slows the program down

Not so you would notice in VB. Sure there are extreme circumstances (e.g. declaring huge arrays) where you might get a performance hit and therefore might consider optimisation, but otherwise I really don't think this is a concern. In fact I'll do a quick timing test...

...Ok, the performance difference in calling a sub with no dims compared to one with (in my test) 24 varied dims is of the order of just under 1 microsecond (approx 0.7 microseconds, in fact).

Heck, even dimensioning a 1 meg array of longs only takes approx 8 milliseconds

>create small memory leaks

Er, dimming a variable in VB is an atomic operation. Not only do I fail to see how an event raised elsewhere on the same thread would cause it to break in such a way that there was a memory leak, but I have also never seen this happen

>I dont like passing variables in the brackets of subs much either as you are dimensioning memory every time you are calling a sub

You know, if sub-microsecond delays are a concern to you, then VB is the wrong language for you to be using (and Windows is probably the wrong OS...)

 

[LazyMe]

tedsmith,
Ever heard of the 80-20 rule (sometimes, and probably even more accurate, called the 90-10 rule)?

Well, if you haven't, it states that about 80 percent of a programs resources are used by about 20 percent of its sourcecode, about 20 percent of the code is responsible for about 80 percent of the binaries runtime etc. etc.

Tuning programs would mean to identify the bottlenecks in the program, the 20% part of it, that is. Yours would definately not be part of that. Especially in this case, where reporting on a database is being performed. No way you will ever get any performance gain on such things as not dimensioning some bytes of memory on the stack.

And the hesitation of passing in arguments in methods would be far off, I guess. A lot of stuff already is being performed. Things are pushed on the stack, jumps are being made, in some cases a return value must be created etc. I don't think that passing in some extra arguments would account for much more processing time....

Greetings,
Rick

 

[tedsmith]

I note your comments but-
I ponder why it should be the golden rule to do anything one way or another?
It is a primitive urge to do what the god says without asking why?
Why would you think that dimensioning variable every time you want to use them is any better than globally dimensioning them all anyway?
Limiting their scope and making subs private is generally known as the preferred way but to me, this often creates confusion, particularly when some are public and some are not.
I was raised in the days of slow computers so speed was more noticeable then.