Regional options: how to change from VB

[Vlad]

I have a problem of different date formats in an international study,
where the data entry module and error checking module are delivered to
the data collecting centres.

Error checking module displays queries for edit specifications, many of
them with dates. For exmple in Sweden, date format is YYYY-MM-DD, this
are how dates are displayed; However, the input mask had been specified
for tables as dd/mm/YYYY. This makes problematic using the error
checking module in Sweden. Solution could be if at start of the
application, the Windows regional settings could be changed for a time
of running the application.
I have not found the way to do this, is it possible at all.
Any suggestions.
--
Vlad

[summerwind]

Hi Vlad

You need to use the DateSerial function.

[Vlad]

Can't see how it can help when dealing with a query based on tables
with specified input masks, which differs from local date format.
summerwind wrote:

Hi Vlad

You need to use the DateSerial function.

--
Vlad

[Allen Browne]

See:
International Date Formats in Access'
at:
http://allenbrowne.com/ser-36.html

The article explains how values entered into the interface will be
interpreted according to the user's settings, how you need to format literal
date values in SQL strings and VBA code, and how to avoid the 3 situations
where Access will misunderstand your dates.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Vlad" <vl************ ******@ktl.fi> wrote in message
news:dr******** **@oxygen.ktl.f i...

Can't see how it can help when dealing with a query based on tables with
specified input masks, which differs from local date format.

[Lyle Fairfield]

A Google search finds numerous examples of code which will do this. One
is:

http://a1vbcode.com/snippet.asp?ID=2722

I have largely given up using such code, preferring to write directly
to the Registry (with code), but that is irrelevant.

I think many developers would do what you propose to do, only as a last
resort, feeling that changing basic User Info should not be done by an
application, worrying that the change might work, with the change-back
failing for whatever reason, and that resulting in something bad
happening with other programs that rely on this setting, and worrying
about any application that might be running concurrently with the
Access application.

TTBOMK, Access/JET/MS-SQL SQLs are all perfectly happy with
#YYYY-MM-DD#, regardless of the ShortDate setting.

Perhaps there is some other safer way to meet your needs which we could
suggest if we knew more.

[Vlad]

Thanks,

I will check this way.
I fact, I need to do this as temporal means to support the process.
1. There is a library of textual modules modeling the sections - part
of the study forms, an library of forms - ordered lists of sections.

2. Program tools in SAS(open VMS) and VBA generate MS Access modules
containing forms, modules and tables for data entering and HTML versions
of the forms being set on the website of the project.

3. The error checking modules are being produced as well, At the moment
manually but it goes also to be automated.

4. All the modules, but error checking, are centre-specific, in terms of
password and user names, fonts used in the text boxes and date input masks.

5. The data entered in the centres are regularly sent to me as MS access
files with tables for pooling and analysis, (SAS database is used).
before sending they automatically are stripped of the confidentional
information. Special interface has been developed to transfer MS access
tables to SAS (Open VMS) data sets. Industry-made means for this are not
available by now.

6. The entry database modules are upgraded and corrected run-time. The
new version are sent to the centres along with the interface module
pumping "old" data in the new tables.
7. Error checking module has dozen of queries grouped by forms which
mimic the original ones, checking the corresponding set of data.

By now, there were no problem with "other" date format, since this was
managed at the level of forms controls linked with fields of tables by
specifying a centre-specific input masks. Though, in tables the input
masks remained the same for all centres.
Queries use input mask of the corresponding fields of tables.
Possible "other" solutions:
1. I can also change input masks for tables, while generating the
database. This, however, will require to change SAS program reading the
CSV files where to the access tables are exported while transferring to
SAS datasets. - I know how to do this, but this requires quite a work
2. Specify input mask in queries, this looks too complex, and don't see
at the moment whether this is possible at all.

--
Vlad

[Lyle Fairfield]

!!!!!!!!!!
Perhaps, changing the setting is the only easy way, then.

[Vlad]

Lyle Fairfield wrote:

!!!!!!!!!!
Perhaps, changing the setting is the only easy way, then.

Thanks for reference, it works.

--
Vladislav Moltchanov Ph.D.

National Public Health Institute
Dept. of Epidemiology and Health Promotion
Mannerheimintie 166, 00300 Helsinki, Finland

Tel: [phone]
Fax: [phone]