Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Access Runtime, Packaging & Deployment _ Foreign Currencies In Runtime Apps

Posted by: ztatzau Feb 18 2020, 01:02 PM

I've recently received inquiries about my Access RT App from potential clients in Europe and South Africa asking if the currency settings can be changed to Euros or Rands rather than American Dollars. I don't see any currency settings or selection in Access Options > Current Database options...

Does a Runtime App simply adopt the Windows OS' currency settings from the computer upon which the RT App is installed?

PLMK! ZT

Posted by: fogline Feb 18 2020, 01:22 PM

Hi ztatzau
I have an Access app that supports 54 Countries with there Currencies.
The way it works is when the end user first starts using your app they will
select there Country and it will set there Currency thru out the program from then on.
I will try to setup a sample app for it ASAP and post it..

Posted by: ztatzau Feb 18 2020, 01:33 PM

Thanks for your reply fogline!

Can you confirm that a RT App WILL NOT automatically adopt the Windows Currency Settings of the computer the App is installed on?

If that is indeed the case, I look forward to seeing your sample!

I do appreciate your help!

ZT

Posted by: fogline Feb 18 2020, 01:43 PM

I have never had no luck getting it to.

Posted by: ztatzau Feb 18 2020, 02:18 PM

Thanks again fogline!

I'll be looking forward to seeing your sample app!

ZT

Posted by: fogline Feb 18 2020, 02:20 PM

Ok Try this sample App
First open the Country Settings form and pick your Country
then open the Sample form. It will show you how to do the code.

I'm sure they may be a better way to do this but this works.
If anyone else would like to modify it please do and re-post it for others to use.

 InternationalCurrency.zip ( 117.61K ): 4

Posted by: FrankRuperto Feb 18 2020, 05:08 PM

Hi ZT,

If you are compiling the FE on your machine that has Win Regional set to USA, and distributing the accde with runtime, maybe the accde is stuck on USA Regional and would need to be recompiled with the target locale set to e.g. Germany? Or perhaps with vba code tell it to use local regional setting?

Posted by: ztatzau Feb 18 2020, 08:36 PM

Thanks again fogline! I have downloaded your sample and will have a look at what you are doing and how you are doing it. I'll post back with any questions.

Thank you too Frank!

RE: "If you are compiling the FE on your machine that has Win Regional set to USA, and distributing the accde with runtime, maybe the accde is stuck on USA Regional and would need to be recompiled with the target locale set to e.g. Germany?"
Yep! That's exactly what I am doing and perhaps this would indeed preclude a RT (ACCDB > ACCDE > ACCDR) APP from adopting the regional settings of the user's machine.

RE: "Or perhaps with vba code tell it to use local regional setting?"
Easy for you to say Frank! What you suggest is likely beyond my current skill level; but could be exactly what fogline's code is doing.

This should keep me busy for a while!

ZT

Posted by: fogline Feb 18 2020, 10:10 PM

Great Good luck with it ZT
I think you will find it simple to use.
If you have any questions let me know.

Posted by: FrankRuperto Feb 19 2020, 12:14 AM

You're welcome ZT. We have several users in different countries. It's been our experience that when we make mods to their frontend's its best to remote into their machines and compile their FE's locally to avoid dependency problems, such as regional settings, reports that are setup to print to specific printers. We are in the process of creating lookup tables for printers, regional settings, display resolutions and storage devices in an attempt to make our apps more portable so we can eliminate hardcoded things like paths in our vba code.

Also keep in mind that when you use VBA to concatenate dates into an AccessSQL query string, you must use a standard U.S. date format, regardless of the locale selected in Windows Regional Settings. Dates can still be displayed in any locale format, however in VBA code, date strings must always be in U.S. format. The following is a custom VBA function that can be used to convert any non-U.S. date format into U.S. date format.

CODE
Function ToDateUS(InDate As Variant) As String

' Exit function if not a valid input date.
If Not IsDate(InDate) then exit function

' Convert input date to a U.S. date format.
ToDateUS = "#" &; Month(InDate) &; "/" &; Day(InDate) &; "/" &; Year(InDate) &; "#"

End Function

Posted by: ztatzau Feb 19 2020, 11:09 AM

Thanks again fogline! Before I start modifying anything and testing, please let me know if I'm correctly understanding your sample and starting off on the right foot. (NOTE: I am, at this point, only concerned with Currency Formats)

Your code...
==========================
Private Sub Form_Load()

Me.AmountTotal.Format = GetSymbol()
Me.Amount.Format = GetSymbol()
' Me.lbUnits.Caption = GetUnitsLable()
' Me.lbDistance.Caption = GetDistanceLable()

End Sub
==========================
... needs to be added to the On_Load event of EACH FORM and REPORT containing any currency fields and the format property setting of EACH SUCH CURRENCY FIELD must be individually referenced in a separate line in the above code? Is that correct?

Thanks again to you too Frank!

RE: "It's been our experience that when we make mods to their frontend's its best to remote into their machines and compile their FE's locally to avoid dependency problems, such as regional settings, reports that are setup to print to specific printers."

I've never remotely accessed my clients machines before and I'm not really comfortable with doing so. And if I understand you correctly, this methodology would also require installing the FE ACCDB on the client's machine, at least initially, in order to compile it locally. DO I have that correct?

As for adding the capability for the user to select specific printers for certain reports, you might like to check out Pere_de_Chipstic's "PrinterSelect Demo" code in the UA Access Code Archive at the following link.

https://www.UtterAccess.com/forum/index.php?showtopic=1982972&hl=printer+select

I've added Pere_de_Chipstick's Printer Select capability to my apps and it has worked very well for me. (Thanks again Bernie!)

RE: "Also keep in mind that when you use VBA to concatenate dates into an AccessSQL query string, you must use a standard U.S. date format, regardless of the locale selected in Windows Regional Settings."


And you raise yet another "Fly in the Ointment" that I hadn't considered. My apps do produce a number of reports that are date, or date range, specific. So if it comes to modifying my app for specific international clients, your date conversion code will be a great help! Thank you again for your help!

ZT

Posted by: fogline Feb 19 2020, 11:17 AM

QUOTE
add this to the On_Load event of EACH FORM and REPORT containing any currency fields and the format property setting of EACH SUCH CURRENCY FIELD must be individually referenced in a separate line in the above code?
Is that correct?


Yes that is all you will need.

Private Sub Form_Load()

Me.FieldName.Format = GetSymbol()

End Sub

In that sample app you can just take out anything to do with the Units and Distance
and just keep the Currency GetSymbol

Posted by: ztatzau Feb 19 2020, 11:57 AM

Thanks fogline! I appreciate your help!
ZT

Posted by: fogline Feb 19 2020, 12:14 PM

Anytime yw.gif
Let me know if you have any trouble with it.

Posted by: ztatzau Feb 19 2020, 01:58 PM

I had another idea as I reconsidered what Frank said above...

"If you are compiling the FE on your machine that has Win Regional set to USA, and distributing the accde with runtime, maybe the accde is stuck on USA Regional and would need to be recompiled with the target locale set to e.g. Germany?"

Because each of my RT Apps are individually created with a significant amount of customization for each user, I'm wondering if it might be a lot easier and solve the currency by building the ACCDB FE as usual (on Win 7 - with Access 2007), and then change the regional settings on my development computer to a specific country before compiling the ACCDB to create a region specific ACCDE.

Any thoughts on the feasibility of this approach would be appreciated!
ZT

Posted by: FrankRuperto Feb 20 2020, 11:20 AM

Test that to see the results. Change Win regional and compile to accde, then install it with the RT on another box that doesnt have full Office Pro, but has the same Win regional setting you have when you compiled the accdb, and see what happens. Also change Win Regional on target box to USA to see what happens

Posted by: fogline Feb 20 2020, 11:52 AM

Frank is there anyway to write any code that would let a end user could just pick the region you want and
have it change the regional settings in the App?

The way you are talking about compiling it to the region that you need is nice I have never thought about doing it that way.

Posted by: FrankRuperto Feb 20 2020, 12:06 PM

There's some examples in this link that shows how to temporarily change Regionals while the Access app is open. The right way to implement it is to put all the constant bit values in a Locales Access table for the countries you want to support and user picks the locale.
https://www.tek-tips.com/viewthread.cfm?qid=1273294

EDIT: This only takes care of regionals, but what about everything else? I have some users who actually have a Microsoft Office Spanish Language Pack installed and the entire Office (Access included) user interface, error messages, etc. are in Spanish.

Posted by: fogline Feb 20 2020, 12:29 PM

Great thanks Frank
I'll check that out.

Posted by: fogline Feb 20 2020, 01:21 PM

Microsoft Office Language Pack ....
That may work also, I'll do some research on that.
Thanks Frank

Posted by: ztatzau Feb 20 2020, 02:09 PM

Thanks FrankI I appreciate your reply...

"Test that to see the results. Change Win regional and compile to accde, then install it with the RT on another box that doesnt have full Office Pro, but has the same Win regional setting you have when you compiled the accdb, and see what happens. Also change Win Regional on target box to USA to see what happens"

I will try this, as soon as current projects allow, and report back. I'm also curious to see how my date/date range specific reports work or don't work with a different regional setting.

EDIT: Please note that my date or date range specific reports are based on Access queries which may behave better than when using VBA to concatenate dates into an AccessSQL query string, as you cautioned about.
Time will tell

ZT

Posted by: FrankRuperto Feb 20 2020, 03:05 PM

You're welcome, guys! There's several ways to "skin the cat" for localizing an Access app. The easiest was with the MS lang packs. However, despite me being fully fluent in Spanish, it took me time to re-adjust since I am so used to seeing the UI and err msgs in English, and some MS translations are truly off_the_wall.
ZT, whichever way your AccessSQL queries are based, make sure the dates in the SQL string appear like e.g. "#02/20/2020#"

Best wishes for success thumbup.gif

Posted by: fogline Feb 20 2020, 03:47 PM

Here may be some helpful Info. "Overview of deploying languages in Office"

https://docs.microsoft.com/en-us/deployoffice/overview-of-deploying-languages-in-office-365-proplus

Posted by: FrankRuperto Feb 20 2020, 07:24 PM

Yes, you can even package your apps with multiple lang packs included, albeit the pkg size grows really big for downloading purposes over the web.
Here's a screenshot from our pawn app, localized for Puerto Rico. Everything is in Spanish. Notice how we don't use any currency symbols for money amounts (the green fonts).
We started out using dual language tables for field captions, lookup table values, built-in pop msgs, etc. and all the user had to do was toggle the UI language cbo to switch, but that became a nightmare to maintain.





 

Posted by: fogline Feb 20 2020, 10:11 PM

That's a good idea not to even use the currency symbols.
All you have to deal with then is the language.
Thanks Frank for all the Info on this. I have so many Mexican truck drivers wanting
me to do a Spanish version of my software.
I think I may look into it now, It may be easier than I thought. thumbup.gif

Posted by: FrankRuperto Feb 20 2020, 11:26 PM

We didn't use currency symbols in the forms, rather color-coded positive money amounts in green and negative amounts in red. Some countries use dots instead of commas for thousands separators. We feel its easier to read money amounts without currency symbols and color-coding against a black background. Colored fonts dont look good against lighter backgrounds. In datasheets, we chose to center certain fields to make it easier to read. All these little details provide a better user experience. However, any report that's considered a legal document, like a contract, invoice, etc. uses the locale's currency symbols, date, time and number formats. In forms and internal reports, users can chose to display in any format they want. In the image of my previous post, the user chose to display short dates as mmm-dd-yyyy while date formats in his locale and most latin-american countries is dd/mm/yyyy or dd.mm.yyyy. When this user enters dates, he uses an mmddyy mask for speedier data entry and format() displays it as mmm-dd-yyyy. Taxes and UOM's (Units Of Measure) also vary. Most Spanish-speaking countries use the metric system, i.e. Liters instead of Gallons for fuel, Km (Kilometers) instead of miles for distances, etc. So in your apps case, I imagine you have fields for fuel and distance. You can provide a combo for units of measure. We did for pawnbrokers, in Puerto Rico they use DWT (Pennyweights) for precious metal weights. Here in the U.S. they use grams. Aside from regional formats, There are several dialects among Spanish-speaking countries. Same words may have different meanings depending on which Spanish-speaking country you are in. Every industry also has its jargon. It will be helpful for you to discuss with trucking companies and drivers in Mexico as to which words to use in your field labels, lookup tables, etc.

hth

Posted by: ztatzau Feb 20 2020, 11:58 PM

Test Results - Compile ACCDB > ACCDE with Regional Settings

"Test that to see the results. Change Win regional and compile to accde, then install it with the RT on another box that doesnt have full Office Pro, but has the same Win regional setting you have when you compiled the accdb, and see what happens. Also change Win Regional on target box to USA to see what happens"

I proceeded as FrankRuperto suggested above and compiled my A2007 ACCDB > ACCDE with A2007 on my Windows 7 development machine with Regional Settings set to South Africa. I then installed, with SSE setup on Virtual Win7 machine... First with Regional Settings set to South Africa and then again with Regional Settings set back to United States

The two results wer identical and there's good news and bad news! The good news is all my date/date range based reports worked just fine even though the date format appeared to display with SA settings' format. The bad news is that all of my currency fields, in forms and reports, still showed the amounts in US $.

I haven't yet given up on this approach and hope to do more testing tomorrow or over the weekend. I'm wondering if the US $ currency symbol that remained unchanged may simply be due to the fact that the underlying (money) Fields in the BE's financial data table are defined as "Currency" Data Type and the underlying data in those fields are stored with the US $ currency symbol.

I'm thinking that it may be better, or perhaps even be common best practice, to save all "money" amounts in a Number field rather than a Currency field and then just set the format for "money" text boxes on forms and reports to Currency. I hope this description is clear and makes sense! Do you guys store "money amounts" in Number fields rather than Currency fields at the table level and format the text boxes on forms and reports as Currency to display the desired currency symbols?

If I can't get the desired regional currency symbols to display (by compiling in a specific region), I may go back to trying fogline's sample forms and code or consider Frank's most recently suggestion of not displaying any currency symbol at all.

Any and all comments appreciated! ZT







Posted by: FrankRuperto Feb 21 2020, 12:33 AM

Hi ZT,

QUOTE
The bad news is that all of my currency fields, in forms and reports, still showed the amounts in US $... I'm wondering if the US $ currency symbol that remained unchanged may simply be due to the fact that the underlying (money) Fields in the BE's financial data table are defined as "Currency" Data Type and the underlying data in those fields are stored with the U.S. $ currency symbol.

First of all, I noticed there are several South Africa locales in regional settings, Which one did you use? The attached image shows the "English (South Africa) settings. So you changed the regionals to an SA in the box you created the accde, packaged it with the RT, installed that on the Win7 VM that also had same regional settings, and it shows a U.S. $ currency symbol instead of R (Rands)? I dont' think Access currency amounts are stored with currency symbols, they're just Number type fields with 2 decimal places, and Access prepends the dollar sign by default when displaying currency fields. Could it be that when you created curency fields, regional settings was en-US?... Another good reason for not defining money amount fields as currency fields. Neutral amounts are more flexible lol.

P.S. Which of the South Africa regionals has SA as a currency symbol?.. The 3 SA's all use an R.
Although you changed regional to an SA, is the system locale setting still set to English (US)? (see iamge)

 

Posted by: ztatzau Feb 21 2020, 11:51 AM

Thanks Frank,

QUOTE
First of all, I noticed there are several South Africa locales in regional settings, Which one did you use? The attached image shows the "English (South Africa) settings. So you changed the regionals to an SA in the box you created the accde, packaged it with the RT, installed that on the Win7 VM that also had same regional settings, and it shows a U.S. $ currency symbol instead of R (Rands)?...

P.S. Which of the South Africa regionals has SA as a currency symbol?.. The 3 SA's all use an R.
Although you changed regional to an SA, is the system locale setting still set to English (US)? (see iamge)


Thanks for pointing out the variety of South African choices Frank. Under the Location Tab (in Region and Language) I chose South Africa. However, under the Formats Tab, when I didn't see South Africa listed with all the "S"s), so I chose Afrikaans (South Africa), never noticing the English (South Africa) listed with all the "E"s. The Afrikaans (South Africa) setting though, should have displayed the Rand ® symbol. I will try again with the other English (South Africa) settings.

QUOTE
I dont' think Access currency amounts are stored with currency symbols, they're just Number type fields with 2 decimal places, and Access prepends the dollar sign by default when displaying currency fields... Another good reason for not defining money amount fields as currency fields. Neutral amounts are more flexible lol.


My BE financial tables definitely store the $ sign along with the money amounts. But I'm quite sure now, as I suspected, that that's because those fields were defined as Currency fields when I created the tables with US settings. I realize now that the better practice must be to define those money table fields as Numbers and format the text boxes that display those money field amounts as Currency.

QUOTE
...Could it be that when you created curency fields, regional settings was en-US?...


Yes! Indeed they were! Which raises another question I've been wondering about. Throughout this discussion, your suggestion was to COMPILE my ACCDB > ACCDE with the target computer's Regional settings. Should I have understood you to mean that I need to RE-CREATE the original ACCDB with the target computer's Regional settings as well as compiling the ACCDB with the same target Regional settings?

ZT

Posted by: cheekybuddha Feb 21 2020, 01:28 PM

>> My BE financial tables definitely store the $ sign along with the money amounts. <<

I doubt it.

Check the field properties and look in the Format section (in the General Tab).

Notice the value is a drop-down list - select 'General Number' instead of 'Currency'.

It is only a format applied to try and be 'helpful'

hth,

d

Posted by: FrankRuperto Feb 21 2020, 01:46 PM

Hi ZT,

QUOTE
Should I have understood you to mean that I need to RE-CREATE the original ACCDB with the target computer's Regional settings as well as compiling the ACCDB with the same target Regional settings?

That would be logical thing to do, but wait a minute... When you created the currency fields with regional set to en-US, shouldn't the $ symbol automatically change to the currency symbol of any regional settings on target box? I find it cumbersome to have to change local regional settings on source box everytime you want to export accde frontend to a target box with different regional settings. I mean, the whole purpose of regional settings is you change them and everything supposed to adjust to new settings.

As to the Access currency type:

QUOTE
age old problem of the Currency field datatype in Access not reflecting the current users regional formatting settings as set in the Operating System.

The problem is that by default, Access stores the format as specified on the developers machine and does not change the formatting if an end user has a different currency format set in their regional settings.


https://www.everythingaccess.com/tutorials.asp?ID=Using-the-Currency-field-data-type-%2D-without-the-hassle

Would like to elaborate more, but I have to run some errands.

hth, ttyl

Posted by: ztatzau Feb 21 2020, 02:08 PM

Thanks for your reply David...

QUOTE
I doubt it.
Check the field properties and look in the Format section (in the General Tab).
Notice the value is a drop-down list - select 'General Number' instead of 'Currency'.

It is only a format applied to try and be 'helpful'

hth, d


https://ibb.co/bWHnbTm
As you can see in the image above, the US $ sign is indeed saved along with each transaction amount.

https://ibb.co/2j6BDxP
In the above image, please also note that, (perhaps mistakenly), the transaction amount field is formatted as Currency. I've always formatted money fields as Currency at the table level. It is perhaps, time for me to re-think this practice!

ZT


Posted by: ztatzau Feb 21 2020, 02:17 PM

Thanks again for your reply Frank...

QUOTE
https://www.everythingaccess.com/tutorials....hout-the-hassle

Would like to elaborate more, but I have to run some errands.

hth, ttyl


I appreciate the link to this article. Hopefully it will help!
Like you though, I need to run a few errands myself but I'll check it out as other priorities permit.

ZT

Posted by: cheekybuddha Feb 21 2020, 02:53 PM

ZT,

I'm not talking about the DataType - that should most definitely be Currency.

Look below (in your second image) in the field properties.

The first line says 'Format: Currency'

Click in 'Currency' and you will be able to select 'General Number'.

This is just to show you that the value is stored as a number. Only Access is adding the '$' sign because that is what it thinks you want to see.

hth,

d

Posted by: ztatzau Feb 21 2020, 03:38 PM

QUOTE
ZT,

I'm not talking about the DataType - that should most definitely be Currency.
Look below (in your second image) in the field properties.
The first line says 'Format: Currency'
Click in 'Currency' and you will be able to select 'General Number'.

This is just to show you that the value is stored as a number. Only Access is adding the '$' sign because that is what it thinks you want to see.

hth, d

Thanks for the explanation David!

Posted by: FrankRuperto Feb 21 2020, 05:17 PM

I'm back... argh, that link I previously posted about Access currency issues is broken, so I had to use the wayback machine to revive it:
https://web.archive.org/web/20171129155201/https://www.everythingaccess.com/tutorials.asp?ID=Using-the-Currency-field-data-type-%2D-without-the-hassle

ZT, David's assertion reaffirms what I mentioned to you before. Access is only storing the values as Number. However, Access is separately storing the currency symbol in effect at the time when the table containing the currency field was created.

Posted by: ztatzau Feb 21 2020, 05:46 PM

I'm back too Frank!

QUOTE
I'm back... argh, that link I previously posted about Access currency issues is broken, so I had to use the wayback machine to revive it:
https://web.archive.org/web/20171129155201/...hout-the-hassle

ZT, David's assertion reaffirms what I mentioned to you before. Access is only storing the values as Number. However, Access is separately storing the currency symbol in effect at the time when the table containing the currency field was created.
This post has been edited by FrankRuperto: Today, 04:25 PM

The link you posted worked fine for me! And though the article is somewhat dated (2009), Wayne Phillips seems to speak with much confidence and experience. The explanation of his methods seems to indicate the change to a local currency symbol should be seemless and depend only on the user's Regional settings. Am I understanding him correctly?

EDIT: Or perhaps is his method only valid for MDB/ACCDB files as opposed to ACCDE/ACCDR files; and return us to the COMPILE with the users Regional setting for RT apps?
ZT

Posted by: FrankRuperto Feb 21 2020, 07:04 PM

QUOTE (zt)
the change to a local currency symbol should be seemless and depend only on the user's Regional settings. Am I understanding him correctly?

Yes

QUOTE
Or perhaps is his method only valid for MDB/ACCDB files as opposed to ACCDE/ACCDR files; and return us to the COMPILE with the users Regional setting for RT apps?

I am inclined to believe it is only valid for mdb/accdb, and would require compiling accdb with same regional settings as target's regional settings, which is a pain. So my opinion is to avoid using Currency fields, or keep them and just remove the symbol in the format property, and use format() to prepend currency symbol only as needed.

Posted by: ztatzau Feb 21 2020, 08:00 PM

Thanks much Frank!

I appreciate your thoughtful comments and advice.

ZT

Posted by: FrankRuperto Feb 21 2020, 11:28 PM

You are welcome, glad I was able to help. One thing we have done to make life easier is to create a VM for each user on our development machine. Each VM has the same Windows OS, Windows setings, Office version, and directory structure as the user's machine. All customers who are using our app have Windows 7 (x64) and Office 2010 Pro (x86) msi versions. Other customers in which we support their apps have a myriad mix of OS and Office versions ranging from WinXP/Office 97 to Win10/Office2016. Some are even OpenSuSE-Linux/PostgreSQL, Oracle and Informix db's.

Posted by: ztatzau Feb 28 2020, 10:08 PM

FOLLOW UP REPORT:

I am happy to report that Wayne Phillips' Everything Access article and methods on "Using the Currency Field Data Type - Without the Hassle", that FrankRuperto suggested above, seem to be working great for me.

I modified my ACCDB BE tables and a few forms and reports in my ACCDB FE exactly as described in Wayne's article on my regular development Win 7 machine with Access 2007.
I then tested the FE & BE ACCDB files with Office 365 CTR on a Win 10 machine with Regional Location and Language settings set to South Africa and English (South Africa).

The few forms and reports that I modified, as per Wane's instructions, all worked perfectly and displayed all the money amounts in the desired SA Rand and currency format.

BUT! I am even more pleased to report that, after compiling my FE ACCDB > ACCDE and renaming ACCDR, still all on my Win7/A2K7 machine with US Regional settings, I performed the same testing with the new ACCDR FE as I did before with the ACCDB FE on the windows 10 machine, and the results were the same as the first test. All the financial forms and reports that I modified displayed the correct SA Rand and currency format.

So it seems to be, so far anyway, that it won't be necessary to compile my ACCDB > ACCDE > ACCDR on a machine with the same regional settings as the target machine!

My client in SA isn't at all concerned with SA vs. US date formats, so I will probably will leave dates formatted as such in table fields and text boxes as they are. However my hunch is that Wayne's methods would work just as well for formatting regional date formats, on the fly at start up using the machine's regional settings, just as well as it seems to be working for currency symbols and formats.


Posted by: PhilS Feb 29 2020, 05:07 AM

QUOTE
My client in SA isn't at all concerned with SA vs. US date formats, so I will probably will leave dates formatted as such in table fields and text boxes as they are. However my hunch is that Wayne's methods would work just as well for formatting regional date formats, on the fly at start up using the machine's regional settings, just as well as it seems to be working for currency symbols and formats.

The weird behavior of Access regarding embedded currency formats discussed in this thread does not apply to Date/Time formats.
If you use generic Date/Time formats (e.g. "Long Date") for your controls, Access will always use the Date/Time formats from Windows Regional settings of the current user of your application.

If you want to use Date/Time formats other than those from the regional settings you can use the Windows API to do the formatting. I wrote the text https://codekabinett.com/rdumps.php?Lang=2&targetDoc=format-date-language-country-vba-access about that topic.

If you want your application to handle multiple currencies at the same time, I would strongly advise not to use any currency formatting at all, but format all currency values as generic numbers and add the currency identifier (symbol or iso-code) in a separate control.

Posted by: ztatzau Feb 29 2020, 01:59 PM

Thanks PhilS! I appreciate your reply and the info you provided.

QUOTE
The weird behavior of Access regarding embedded currency formats discussed in this thread does not apply to Date/Time formats.
If you use generic Date/Time formats (e.g. "Long Date") for your controls, Access will always use the Date/Time formats from Windows Regional settings of the current user of your application.

I did notice, during my ACCDR testing, that some of my date controls on forms and reports appeared with the regional formats of the target machine (SA) while other controls retained their original (US) date formats.
I haven't dug into this issue yet, but from what you say, I'm guessing that the controls that adopted the SA date formats were formatted "Short Date, Long Date, etc.", whereas the controls that retained their US date formats are likely formatted as "mm/dd/yyyy", etc. Would you agree?

ZT

Posted by: PhilS Mar 1 2020, 09:45 AM

QUOTE
I haven't dug into this issue yet, but from what you say, I'm guessing that the controls that adopted the SA date formats were formatted "Short Date, Long Date, etc.", whereas the controls that retained their US date formats are likely formatted as "mm/dd/yyyy", etc. Would you agree?

Yes, I agree; that is a very common problem.

If you are interested, I've got some more info on Date/Time in international scenarios in my article https://codekabinett.com/rdumps.php?Lang=2&targetDoc=date-time-data-type-vba-access; but the already mentioned rule of using named format instead of explicit format strings is the most important.

Posted by: ztatzau Mar 1 2020, 01:19 PM

Thanks again PhilS!

I've saved both of the articles you mentioned and look forward to learning more about Date/Time formatting for international use.

ZT