a bug or an error?(date function)

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have use date function in my report.it bound to text like this
"=IIf(Month(Date())>6;Year(Date()) & "/" & Year(Date())+1;Year(Date()))",

it works well on my own computer(my computer is install winxp pro and office
2003).but it can't run in a computer which install windows2003 server and
office 2003. If i run this report in the windows2003 ,it will let me to fill
the date.becase it can't recognize the fuction date?().
why this happened? is it a bug or my error?
 
Null said:
I have use date function in my report.it bound to text like this
"=IIf(Month(Date())>6;Year(Date()) & "/" &
Year(Date())+1;Year(Date()))",

it works well on my own computer(my computer is install winxp pro and
office 2003).but it can't run in a computer which install windows2003
server and office 2003. If i run this report in the windows2003 ,it
will let me to fill the date.becase it can't recognize the fuction
date?(). why this happened? is it a bug or my error?

Often when databases don't work on one particular machine, it's because
of a broken or missing reference. See if the steps outlined here help:


http://members.rogers.com/douglas.j.steele/AccessReferenceErrors.html
 
I have use date function in my report.it bound to text like this
"=IIf(Month(Date())>6; _
Year(Date()) & "/" & Year(Date())+1; _
Year(Date()))",

it works well on my own computer(my computer is install winxp pro and
office 2003).but it can't run in a computer which install windows2003
server and office 2003.


I notice you are using semicolons for the separators, which is presumably
specified in your Regional Settings. I don't know how VBA code gets
translated from one language settings to another, but it might be
worthwhile checking to see that the target machine has commas in the code
(or else is set to use semicolons for list separators). Do Server Versions
of windows have more restricted locality settings than workstations?

Just a thought


Tim F
 
I have try the method whch Dirk Goldgar told me,but the problem still exist.I
also check Regional setting that Tim Ferguson mention.I change the Regional
that as same as the computer which can perfect run this programme.the problem
can't be solved.I have no idea about that.

I used semicolons for the separators becase of when i trying to use the
comma for separators.it pops an error( I used english edition office2003).so
I doubt that the online book is wrong that told us to use comma for
separators in IIF function.

thanks for all.
 
I used semicolons for the separators becase of when i trying to use
the comma for separators.it pops an error( I used english edition
office2003).so I doubt that the online book is wrong that told us to
use comma for separators in IIF function.

Having reread your original question more closely, I don't think that the
semicolons are the problem; although I still don't know how well different
separators do transfer from one language to another. Are you German?

My best guess would be a missing reference. Access is fussy about these;
any missing reference (even not related to VBA itself) can mess up basic
VBA functions.

All the best


Tim F
 
Tim Ferguson:
You are right,that's because the missing reference.when I reselect the
reference,I found some of it are not exists.so I chose the update the
edition.or a close edition.
so it can work fine.
HAHA,that's the solution for the problem.
thanks Tim.thanks for what you have done for me.And thanks for everyone.
 
Tim Ferguson:

You are right, that’s because the missing reference.

When I reselect the reference, I found some of them are not exists. What I
have done to solve the problem is:
1. Disable irrelevant reference on the client workstation.
2. Enable related reference even through it is lower version on the client
workstation.

I also found that some of the references were checked automatically when I
do it. Can I disable them manually? For example, I don't need DAO object, but
it selected automatically by MS Office.

It works fine now. Thanks Tim. Thanks for what you have done for me. And
thanks for everyone.

I have another question? How can I distribute my program to avoid this error
to occur?
Should I use the package tools?
 
I have another question? How can I distribute my program to avoid this
error to occur?
Should I use the package tools?

The references you set are contained in the mdb or mde file that you
distribute, so once they are correct they _should_ stay correct.
Unfortunately, broken references are a recurring problem and may be
affected by:

+ missing libraries on the destination machine: applies obviously to any
custom ActiveX components you use, but you would be distributing them
anyway; but also to "optional" MS components like Scripting which might
have been removed

+ changed libraries: you can run into problems with versions, for example
when you have a reference to Calendar7.0 and your customer has v8. This is
why many people recommend using "late binding" or even direct access to the
DLLs, etc.

+ Murphy's law: sometimes references just seem to break because the weather
is wrong! Strange things can happen when a mdb travels from one PC to
another.

I don't think there is anything a packaging tool can do to prevent it: just
be vigilant and prepare to help out the customer if neccessary.

Hope that helps


Tim F
 
Back
Top