Could not start number field with 0?

[ontherun]

Hi,

I have a field to enter mobile number (10 digits) for customers and it starts with '0'
whenever i enter the number, it does not accept zero at the front.
if i enter: 0411111111, it will end up like-- 4111111111

how should i rectify this??
can anyone help in this regard,

thanks,
catherine

[Jim Doherty]

Hi,

I have a field to enter mobile number (10 digits) for customers and it starts with '0'
whenever i enter the number, it does not accept zero at the front.
if i enter: 0411111111, it will end up like-- 4111111111

how should i rectify this??
can anyone help in this regard,

thanks,
catherine

Set your data type field size to 'double' and in the FORMAT type 0000000000

Jim

[missinglinq]

Simply set the datatype to Text! Just because a field holds digits doesn't mean it should be defined as numerical! It doesn't need to be defined as a numerical datatype unless it's to be used in mathematical calculations!

SSNs, ID numbers, phone numbers, etc. are not numerical data!

Linq ;0)>

[ontherun]

Simply set the datatype to Text! Just because a field holds digits doesn't mean it should be defined as numerical! It doesn't need to be defined as a numerical datatype unless it's to be used in mathematical calculations!

SSNs, ID numbers, phone numbers, etc. are not numerical data!

Linq ;0)>

hi,

thanks for your reply.
I tried both the options but i have entered some records with my previous settings.
so some of the mobile no have been saved as 411111111 instead of 0411111111

now when i change the data type and save the table, i tried to change the values but it is not allowing me still.

what could be the reason?

waiting for your reply.

thanks,
catherine

[ontherun]

hi,

thanks for your reply.
I tried both the options but i have entered some records with my previous settings.
so some of the mobile no have been saved as 411111111 instead of 0411111111

now when i change the data type and save the table, i tried to change the values but it is not allowing me still.

what could be the reason?

waiting for your reply.

thanks,
catherine

Hi there,

I checked in the tables and all mobile numbers starts with 0 as i entered for the first time. like

but when i open in forms, the same mobile numbers does not start with 0.

am totally confused

[Jim Doherty]

Hi there,

I checked in the tables and all mobile numbers starts with 0 as i entered for the first time. like

but when i open in forms, the same mobile numbers does not start with 0.

am totally confused

Miss Ingling is 100 percent correct!

My answer based on your question how do I store a mobile NUMBER where it allows you to display the leading zero is answered by my posting ie double using 0000000000 as the format does gives it you visually. MissIngling properly points out that the datatype storage text should have been the datatype of choice in the first place.

My 'assumption' based on your specific question was that you might have chosen numeric for a particular specific reason ie: a MOBILE number is hardly likely to have an alpha character in it which, if this had been your concious choice, would give you the advantage of easy SORTING over a 'massive' dataset processing quicker than text based on WHERE clauses and so with =><<> operands etc.

I have no way of knowing what might prompt cause you to use numeric but you obviously have and looking at my posting compared with Miss Ingling looks as though I am giving you WRONG advice.

IT IS a question as has been quite rightly pointed of suitably determining your datatype requirement properly in the 'first place' in the full knowledge of how each datatype reacts. With TEXT based overall you have no problem entering and/or validating on a string length of TEN digits all of which must be numbers containing no inadvertent spaces, unwanted characters etc etc and their are various ways to do that.

In your specific situation you see the numbers in the table per se displayed now as you want but the FORM control ie the textbox doesnt see it that way, it sees it as a number, but not its format.

The format property for the textbox control if set to 0000000000 will display any number as entered as a TEN sequence so the number 345 will show as 0000000345. IF you are content with this and it suits your purpose.... then you make the choice..... but if not and it of course may not be suitable, then you convert the existing data to text based, deal with historical data not having a leading zero by whatever means is at your disposal and go for validating the text string number for future inserts its up to you

Hope I have qualified myself sufficiently so as NOT to potentially steer you down the wrong route. Bottom line is you must know HOW your datatypes behave and how you can successfully query on any data reproduced before committing data to it.

Example: Using the NUMBER method you will never be able to simply type 0000087345 as criteria in the Access query grid because Access will throw the leading zeros away leaving you with 87345 you' would still get a return dataset of course but you might think "hmmmm why did it do that"...it does it because its a number!!

I hope this qualifies my earlier one line posting to you?

Regards

Jim

[ontherun]

Miss Ingling is 100 percent correct!

My answer based on your question how do I store a mobile NUMBER where it allows you to display the leading zero is answered by my posting ie double using 0000000000 as the format does gives it you visually. MissIngling properly points out that the datatype storage text should have been the datatype of choice in the first place.

My 'assumption' based on your specific question was that you might have chosen numeric for a particular specific reason ie: a MOBILE number is hardly likely to have an alpha character in it which, if this had been your concious choice, would give you the advantage of easy SORTING over a 'massive' dataset processing quicker than text based on WHERE clauses and so with =><<> operands etc.

I have no way of knowing what might prompt cause you to use numeric but you obviously have and looking at my posting compared with Miss Ingling looks as though I am giving you WRONG advice.

IT IS a question as has been quite rightly pointed of suitably determining your datatype requirement properly in the 'first place' in the full knowledge of how each datatype reacts. With TEXT based overall you have no problem entering and/or validating on a string length of TEN digits all of which must be numbers containing no inadvertent spaces, unwanted characters etc etc and their are various ways to do that.

In your specific situation you see the numbers in the table per se displayed now as you want but the FORM control ie the textbox doesnt see it that way, it sees it as a number, but not its format.

The format property for the textbox control if set to 0000000000 will display any number as entered as a TEN sequence so the number 345 will show as 0000000345. IF you are content with this and it suits your purpose.... then you make the choice..... but if not and it of course may not be suitable, then you convert the existing data to text based, deal with historical data not having a leading zero by whatever means is at your disposal and go for validating the text string number for future inserts its up to you

Hope I have qualified myself sufficiently so as NOT to potentially steer you down the wrong route. Bottom line is you must know HOW your datatypes behave and how you can successfully query on any data reproduced before committing data to it.

Example: Using the NUMBER method you will never be able to simply type 0000087345 as criteria in the Access query grid because Access will throw the leading zeros away leaving you with 87345 you' would still get a return dataset of course but you might think "hmmmm why did it do that"...it does it because its a number!!

I hope this qualifies my earlier one line posting to you?

Regards

Jim

thanks Jim. that gives me a clear understanding of where i went wrong and what exactly i should do.

thanks a lot again..

i'll follow your steps as stated.

have a good weekend

regards,
Catherine