... and a simple INSTR() function could have located any commas within your floating-point numbers and allowed you to change them into periods where required. Telling users to change their regional settings to accomodate your app may have seemed like a quick fix, but I am a firm believer that apps should always accomodate the user, not the other way around. Any app intended for international use should never force someone into a particular date or number format. You should test for regional settings first and then have your app adjust internally to accomodate the user's settings.

I'm fortunate in that all our old apps used serial dates from the very beginning. (We had a set of custom serial date routines long before MS implemented them in VB. Damn, I should have pantented those.. LOL) All string representations of dates get converted to serial format and then regional settings do not matter until you need to convert the date back to a string for display. So regional settings should only come into play when retrieving user input and displaying your output.

Actually, Peter's example works any where as it stands, because he used the value #1/1/2000#. While #06/07/05/# would depend upon regional settings, his number does not. It's a fine point and why I prefer DateSerial(yyyy,mm,dd) or #dd/mmm/yyyy# to avoid possible regional issues.