database works for some users in runtime but not others

[Guest]

I have created a database - tables, forms, reports, macros - nothing hand
coded. Database works fine in full version. In runtime environment it works
for some users but not others (even on the same machine).

I have tried changing user rights locally but no joy. I have noticed that
the user for whom the database works has an MDW file associated with their
profile but no idea where it came from.

Any help much appreciated

 

[Albert D.Kallal]

Hum, this perhaps is a references problem.

However, you should "test" the application on your machine, and can do so in
runtime mode by adding the

/runtime

Switch to your startup.

So, you can "test" what it will work like on your machine.

Also, by "not works" is a rather non description here.

Also, you should be distributing a mde to these users...are you ?

Also...what version are you using....

 

[Guest]

Hi Albert, thanks for the response. using Access 2003 and runtimes from
Office pro 2003.

Problem experienced in runtime in roaming profile environment with some
users only.

Specifically. opening a form with a user defined date filter fails.

The application runs in runtime on my computer no problem.

Problem occurs only with some users and not others.

Have not tried MDE as the application is not working - should this really
make a difference - does this not just protect the code?

 

[Albert D.Kallal]

Problem experienced in runtime in roaming profile environment with some
users only.

Specifically. opening a form with a user defined date filter fails.

Well, it sounds like a broken reference, or your might have a date format
setting problem. Often, on a problem machine, you will find out that the
user has changed he date format. Your code might expect mm/dd/yyyy, and the
user has it set to

d/m/yyyy

So, you might want to check how that filter code works.

The application runs in runtime on my computer no problem.

Ok...good, you tested the /runtime switch..and that is nice to get that
problem out of the way.

Problem occurs only with some users and not others.

Do you mean some users on he SAME computer...are you talking about a
different computer?

Have not tried MDE as the application is not working - should this really
make a difference - does this not just protect the code?

Well, it means you have made at least a MINIMAL effort to determine that
your code compiles. It means that you at least make a lame effort to ensure
that your code does not go out the door with compile errors. We don't want
to send out an application with compile errors...do we? I could ask if your
code compiles...but by asking you if you are using a mde, then it means you
do take some efforts to ensure your code compiles before you sent it out.
So, I could rephrase the question...and ask does your code have any compile
errors? Worse, are you perhaps sending out a application that is not
compiled for those users (this can be a source of bloat..or additional
problems due to code "trying" to compile as it runs. Really, a dumb thing to
have happen, and you can avoided this by simply adopting a policy of
distributing a mde. Those mdes are smaller, run faster..and can't become
un-compiled state like a mdb with the source code in it).

So, since this *might* be a date issue, we narrowed it down to a best guess
of references. However, you seem to hint that some users on the SAME
computer work...and some don't....so, the next best guess would be the users
"date" settings in the control panel.

You need to ensure that your code does NOT care about the users internal
date settings. That means that users can change their default date format in
the windows panel, but YOU MUST ALWAYS use the USA format in your code. That
means:

strFilter = "InvoiceDate between #" & format(dtStart,"mm/dd/yyyy") & "# " &
_
" and #" & format(dtEnd,"mm/dd/yyyy") & "#"

Note how we use the format command to "cast" the fomrat of the date to USA
format.....

 

[Guest]

Thanks for the post.

Problem does not appear to be date settings. The form actually fails prior
to the date being imput - The form fails to appear - and neither does the
expected dialogue box for date entry.

Problem appears to be one of security settings / user rights. e.g. same user
/ any computer experiences the problem where as another user/ any computer
enjoys full experience.

This is not the first time I have experienced the problem and only method of
overcoming was to wipe profile and start again (really want to avoid this as
the database involved might be quite widely used).

Not sure what more to tell you but any help appreciated.

Thanks

 

[Albert D.Kallal]

Ok, perhaps you should force the workgroup file via the shortcut you use
just to be sure that it is not a workgroup file issue.

Also, we assume a split database?? Is this application multi-user?

You can read why you need to split here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm