UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
> Foreign Currencies In Runtime Apps, Any Version    
 
   
ztatzau
post Feb 18 2020, 01:02 PM
Post#1



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
Start new topic
Replies
fogline
post Feb 18 2020, 01:22 PM
Post#2



Posts: 218
Joined: 5-August 15
From: Ringgold, GA. USA


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..

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
ztatzau
post Feb 18 2020, 01:33 PM
Post#3



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
fogline
post Feb 18 2020, 01:43 PM
Post#4



Posts: 218
Joined: 5-August 15
From: Ringgold, GA. USA


I have never had no luck getting it to.

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
fogline
post Feb 18 2020, 02:20 PM
Post#5



Posts: 218
Joined: 5-August 15
From: Ringgold, GA. USA


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.

Attached File  InternationalCurrency.zip ( 117.61K )Number of downloads: 4

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
ztatzau
post Feb 19 2020, 01:58 PM
Post#6



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
ztatzau
post Feb 20 2020, 02:09 PM
Post#7



Posts: 374
Joined: 4-April 07



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
This post has been edited by ztatzau: Feb 20 2020, 02:32 PM
Go to the top of the page
 
FrankRuperto
post Feb 20 2020, 03:05 PM
Post#8



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
fogline
post Feb 20 2020, 03:47 PM
Post#9



Posts: 218
Joined: 5-August 15
From: Ringgold, GA. USA


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

Overview of Deploying Languages in Office
This post has been edited by fogline: Feb 20 2020, 03:48 PM

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
FrankRuperto
post Feb 20 2020, 07:24 PM
Post#10



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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.




Attached File(s)
Attached File  SpanishApp.PNG ( 256.12K )Number of downloads: 11
 

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
fogline
post Feb 20 2020, 10:11 PM
Post#11



Posts: 218
Joined: 5-August 15
From: Ringgold, GA. USA


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

--------------------
Ray White - Fog Line Software LLC.
Email
Go to the top of the page
 
ztatzau
post Feb 20 2020, 11:58 PM
Post#12



Posts: 374
Joined: 4-April 07



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






Go to the top of the page
 
FrankRuperto
post Feb 21 2020, 12:33 AM
Post#13



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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)
This post has been edited by FrankRuperto: Feb 21 2020, 01:11 AM
Attached File(s)
Attached File  English__SA_.PNG ( 77.64K )Number of downloads: 4
Attached File  SystemLocale.PNG ( 95.31K )Number of downloads: 4
 

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
ztatzau
post Feb 21 2020, 11:51 AM
Post#14



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
cheekybuddha
post Feb 21 2020, 01:28 PM
Post#15


UtterAccess Moderator
Posts: 12,849
Joined: 6-December 03
From: Telegraph Hill


>> 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

--------------------


Regards,

David Marten
Go to the top of the page
 
ztatzau
post Feb 21 2020, 02:08 PM
Post#16



Posts: 374
Joined: 4-April 07



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



As you can see in the image above, the US $ sign is indeed saved along with each transaction amount.


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

Go to the top of the page
 
ztatzau
post Feb 21 2020, 02:17 PM
Post#17



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
cheekybuddha
post Feb 21 2020, 02:53 PM
Post#18


UtterAccess Moderator
Posts: 12,849
Joined: 6-December 03
From: Telegraph Hill


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

--------------------


Regards,

David Marten
Go to the top of the page
 
ztatzau
post Feb 21 2020, 03:38 PM
Post#19



Posts: 374
Joined: 4-April 07



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!
Go to the top of the page
 
FrankRuperto
post Feb 21 2020, 05:17 PM
Post#20



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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: Feb 21 2020, 05:25 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
ztatzau
post Feb 21 2020, 05:46 PM
Post#21



Posts: 374
Joined: 4-April 07



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
This post has been edited by ztatzau: Feb 21 2020, 05:50 PM
Go to the top of the page
 
FrankRuperto
post Feb 21 2020, 07:04 PM
Post#22



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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.
This post has been edited by FrankRuperto: Feb 21 2020, 07:08 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
ztatzau
post Feb 21 2020, 08:00 PM
Post#23



Posts: 374
Joined: 4-April 07



Thanks much Frank!

I appreciate your thoughtful comments and advice.

ZT
Go to the top of the page
 
FrankRuperto
post Feb 21 2020, 11:28 PM
Post#24



Posts: 1,012
Joined: 21-September 14
From: Tampa, Florida USA


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.
This post has been edited by FrankRuperto: Feb 21 2020, 11:51 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
ztatzau
post Feb 28 2020, 10:08 PM
Post#25



Posts: 374
Joined: 4-April 07



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.

Go to the top of the page
 
PhilS
post Feb 29 2020, 05:07 AM
Post#26



Posts: 697
Joined: 26-May 15
From: The middle of Germany


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 Formatting Date/Time for a specific language and country in Access and VBA 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.

--------------------
A professional Access developer tool: Find and Replace for Access and VBA
Go to the top of the page
 
ztatzau
post Feb 29 2020, 01:59 PM
Post#27



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 
PhilS
post Mar 1 2020, 09:45 AM
Post#28



Posts: 697
Joined: 26-May 15
From: The middle of Germany


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 The Date Data Type in VBA and Access; but the already mentioned rule of using named format instead of explicit format strings is the most important.

--------------------
A professional Access developer tool: Find and Replace for Access and VBA
Go to the top of the page
 
ztatzau
post Mar 1 2020, 01:19 PM
Post#29



Posts: 374
Joined: 4-April 07



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
Go to the top of the page
 

Posts in this topic
- ztatzau   Foreign Currencies In Runtime Apps   Feb 18 2020, 01:02 PM
- - fogline   Hi ztatzau I have an Access app that supports 54 C...   Feb 18 2020, 01:22 PM
- - ztatzau   Thanks for your reply fogline! Can you confir...   Feb 18 2020, 01:33 PM
- - fogline   I have never had no luck getting it to.   Feb 18 2020, 01:43 PM
- - ztatzau   Thanks again fogline! I'll be looking for...   Feb 18 2020, 02:18 PM
- - fogline   Ok Try this sample App First open the Country Sett...   Feb 18 2020, 02:20 PM
- - FrankRuperto   Hi ZT, If you are compiling the FE on your machin...   Feb 18 2020, 05:08 PM
|- - ztatzau   Thanks again fogline! I have downloaded your ...   Feb 18 2020, 08:36 PM
|- - fogline   Great Good luck with it ZT I think you will find i...   Feb 18 2020, 10:10 PM
|- - FrankRuperto   You're welcome ZT. We have several users in di...   Feb 19 2020, 12:14 AM
|- - ztatzau   Thanks again fogline! Before I start modifyin...   Feb 19 2020, 11:09 AM
|- - fogline   QUOTE add this to the On_Load event of EACH FORM a...   Feb 19 2020, 11:17 AM
|- - ztatzau   Thanks fogline! I appreciate your help! Z...   Feb 19 2020, 11:57 AM
|- - fogline   Anytime Let me know if you have any trouble wit...   Feb 19 2020, 12:14 PM
- - ztatzau   I had another idea as I reconsidered what Frank sa...   Feb 19 2020, 01:58 PM
- - FrankRuperto   Test that to see the results. Change Win regional ...   Feb 20 2020, 11:20 AM
|- - fogline   Frank is there anyway to write any code that would...   Feb 20 2020, 11:52 AM
|- - FrankRuperto   There's some examples in this link that shows ...   Feb 20 2020, 12:06 PM
|- - fogline   Great thanks Frank I'll check that out.   Feb 20 2020, 12:29 PM
|- - fogline   Microsoft Office Language Pack .... That may work ...   Feb 20 2020, 01:21 PM
- - ztatzau   Thanks FrankI I appreciate your reply... "T...   Feb 20 2020, 02:09 PM
- - FrankRuperto   You're welcome, guys! There's several ...   Feb 20 2020, 03:05 PM
- - fogline   Here may be some helpful Info. "Overview of...   Feb 20 2020, 03:47 PM
- - FrankRuperto   Yes, you can even package your apps with multiple ...   Feb 20 2020, 07:24 PM
- - fogline   That's a good idea not to even use the currenc...   Feb 20 2020, 10:11 PM
- - FrankRuperto   We didn't use currency symbols in the forms, r...   Feb 20 2020, 11:26 PM
- - ztatzau   Test Results - Compile ACCDB > ACCDE with Regio...   Feb 20 2020, 11:58 PM
- - FrankRuperto   Hi ZT, QUOTE The bad news is that all of my curre...   Feb 21 2020, 12:33 AM
- - ztatzau   Thanks Frank, QUOTE First of all, I noticed there ...   Feb 21 2020, 11:51 AM
- - cheekybuddha   >> My BE financial tables definitely store t...   Feb 21 2020, 01:28 PM
|- - ztatzau   Thanks for your reply David... QUOTE I doubt it. ...   Feb 21 2020, 02:08 PM
|- - ztatzau   Thanks again for your reply Frank... QUOTE https:...   Feb 21 2020, 02:17 PM
|- - cheekybuddha   ZT, I'm not talking about the DataType - that...   Feb 21 2020, 02:53 PM
|- - ztatzau   QUOTE ZT, I'm not talking about the DataType ...   Feb 21 2020, 03:38 PM
|- - FrankRuperto   I'm back... argh, that link I previously poste...   Feb 21 2020, 05:17 PM
|- - ztatzau   I'm back too Frank! QUOTE I'm back......   Feb 21 2020, 05:46 PM
|- - FrankRuperto   QUOTE (zt)the change to a local currency symbol sh...   Feb 21 2020, 07:04 PM
|- - ztatzau   Thanks much Frank! I appreciate your thoughtf...   Feb 21 2020, 08:00 PM
|- - FrankRuperto   You are welcome, glad I was able to help. One thi...   Feb 21 2020, 11:28 PM
|- - ztatzau   FOLLOW UP REPORT: I am happy to report that Wayne...   Feb 28 2020, 10:08 PM
|- - PhilS   QUOTE My client in SA isn't at all concerned w...   Feb 29 2020, 05:07 AM
|- - ztatzau   Thanks PhilS! I appreciate your reply and the...   Feb 29 2020, 01:59 PM
|- - PhilS   QUOTE I haven't dug into this issue yet, but f...   Mar 1 2020, 09:45 AM
|- - ztatzau   Thanks again PhilS! I've saved both of th...   Mar 1 2020, 01:19 PM
- - FrankRuperto   Hi ZT, QUOTE Should I have understood you to mean...   Feb 21 2020, 01:46 PM



Custom Search


RSSSearch   Top   Lo-Fi    4th June 2020 - 10:08 PM