I have table invoice inside an access mdb that stores DECIMAL in Italian format. ie , is used as the decimal separator.
So thousand will be written as 1.000,00. I would like to change it to UK format like this 1000.00. For this I use this query.
UPDATE invoice SET invoice_amount = Replace(Replace(invoice_amount,'.',''),',','.')
Are there any better options? I am also afraid that an accidental run of this query a second time makes 1000.00 become 100000. Any straight forward fool proof way to change culture here?
P.S: invoice_amount is of type Text here.
Related
I coded a program for work to keep tracks of our projects linked to an access database. The code is written in VB.NET
The thing is I use a computer with dates in French. The whole thing is coded according to that language. But now I have to install the program on all the computers in the company (some are in French and som in English). I can't change the language of the english computers because of another program they're using.
So how can I make my program to work with English dates?
I tried to detect the language of the computer this way:
CultureInfo.CurrentCulture.DisplayName
And then to convert the Today date to French (I'm using the Today date to compare it to a due date for "Alarms" to prevent us when a project is late or due for today):
Today = Today.toString(CultureInfo.CreateSpecificCulture("fr-CA")
But this doesn't seem to be the right way to do it since my program doesn't load afterwards.
If you have any idea, I'm willing to read them
Thanks guys
Based on that description, there is no problem other than the one you are creating. DO NOT convert dates/times to Strings unless you actually need Strings. You do not.
In the case of the DateTimePicker, you simply set the Format to Long or Short and the user will then see dates in a format appropriate to their system, based on their current culture settings. In code, you get a DateTime value from the Value property and that is a binary value, so format is irrelevant.
In the case of the DataGridView, if you have a column that contains DateTime values then they will be displayed in a format based on the current culture. The underlying values are binary so they have no format but the grid must use a format for display purposes. Each user will see what they expect because the system's culture settings will be used to perform that format. If you don't like the format used, you can set the DefaultCellStyle.Format property of the column to "D" or "d" to match the Long and Short formats of the DateTimePicker respectively.
As I said, the values in the cells of such a column are DateTime values, not Strings, so format is irrelevant. If you want to compare them with today's date then you do so in binary format, e.g.
If CDate(myDataGridViewCell.Value) > Date.Today Then
At no point do you have to worry about format because the application will use the current system culture settings automatically anywhere that format is an issue.
I need verify that all cells in column contain data in only date format. How it possible to verify?
*I think it isn't LIKE function.
DATE doesn't have any format. What you see is for display purpose so that it could be easily interpreted.
DATE datatype is stored in a proprietary format internally in 7 bytes. It is a bad idea and makes no sense to verify the format while date is stored in an internal format. As I said, format is only for display.
If the date column is not a DATE data type, then it is a design flaw. And, any application based on such a flawed database design is on the verge to break anytime.
Storing DATE values other than date data type is just like not understanding the basics.
You should first fix the design to get a permanent solution. Any solution to your question is just another workaround.
Let me show a small example how it creates even more confusion.
The following date :
01/02/2015
Is it:
1st Feb 2015 or,
2nd Jan 2015
There is no way to tell that. It could be either DD or MM. This being just one among so many other problems due to the incorrect data type.
Store date values as DATE data type only, period.
Based on your last question, I think you are looking for something like this:
SELECT COUNT(*) FROM ...
WHERE NOT REGEXP_LIKE (A, '^XXX/MOSCOW/XXXMSX/[0-9]{4}-[0-9]{2}-[0-9]{2}$')
If count is greater than zero, something doesn't match. If you want more detail on what doesn't match, change your SELECT clause appropriately.
If you are looking for multiple date formats, you can change your regular expression appropriately. The | operator in most flavors of regular expression, including Oracle's, lets you define multiple patterns in the same space. You might use something like
SELECT COUNT(*) FROM ...
WHERE NOT
REGEXP_LIKE (A,
'^XXX/MOSCOW/XXXMSX/[0-9]{4}-[0-9]{2}-[0-9]{2}$|^[0-9]{4}-[0-9]{2}-[0-9]{2}$')
adding as many different matching patterns as you need.
Try
SELECT *
FROM POL
WHERE NOT REGEXP_LIKE(TR_KRY, '^(0[1-9]|([1-2][0-9])|30|31)-(([0][1-9])|10|11|12)-[0-9]{4}$')
This will return you all rows where TR_KRY is not formatted as 'DD-MM-YYYY', where DD is '01'-'31', MM is '01'-'12', and YYYY is any four numeric digits.
As others have said, storing dates as character strings is not a good idea. In the field you're looking at, it might be that the date is stored as DD-MM-YYYY (day-month-year - the usual case in Europe and perhaps elsewhere), or it might be that the date is stored as MM-DD-YYYY (month-day-year - a common practice in the US). If possible, I suggest you should convert this field to the DATE data type so that the TO_CHAR function can be used to produce a text version of the date in whatever format is desired.
Given the example data you've shown in comments (and that's also not good practice - you should go back and edit the question when you want to include additional information) it appears the dates are formatted as DD-MM-YYYY and I've set up the regular expression above to deal with this as best as possible.
I would like to change the manner in which the mileage is represented in the database. For example, right now the mileage is represented as 080+0.348; this would mean that this particular feature is at mileage point 80.348 along the roadway corridor. I would like to have the data represented in the database in the latter form, 80.348 and so on. This would save me from having to export the dataset to excel for the conversion. Is this even possible? The name of the column is NRLG_MILEPOINT.
Much appreciated.
One thing you could try is to pick the string value apart into its component pieces and then recombine them as a number. If your data is in a table called TEST you might do something like the following:
select miles, fraction,
nvl(to_number(miles), 0) + nvl(to_number(fraction), 0) as milepoint
from (select regexp_substr(nrlg_milepoint, '[0-9]*') as miles,
regexp_substr(nrlg_milepoint, '[+-][0-9.]*') as fraction
from test);
SQLFiddle here.
Share and enjoy.
Using the answer provided above, I was able to expand it to get exactly the answer i needed. Thanks a ton to everyone who helped! Here is the query i ended up with:
select distinct nrlg_dept_route,corridor_code_rb,nrlg_county,next_county,
nvl(to_number(miles), 0) + nvl(to_number(fraction), 0) as milepoint
from (select regexp_substr(nrlg_milepoint, '[0-9]*') as miles,
nrlg_milepoint as nrlg_mile_point
nrlg_dept_route as nrlg_dept_route,
nrlg_county as nrlg_county,
next_county as next_county,
corridor_code_rb as corridor_code_rb,
corridor_code as corridor_code,
regexp_substr(nrlg_milepoint, '[+-][0-9.]*') as fraction
from corridor_county_intersect,south_van_data_view)
where nrlg_dept_route = corridor_code
order by 1,5;
There are a variety of ways to do this. Which one depends on your situation, how the data needs to be stored, and how it is being interacted with. Some of these options include:
Changing the datatype.
This option would potentially require you to change how the data is being stored currently. The conversion of the data would have to be done by whatever is writing the data to the schema currently.
Creating another column that stores the data in the correct format.
If you have an existing means of storing the data that would be broken by changing the datatype of NRLG_MILEPOINT and/or you have a requirement to store the data in that format; you could optionally add another column... say NRLG_MILEAGE_DISPLAY that is of a datatype number perhaps, and store the data there. You could make a trigger that updates/inserts NRLG_MILEAGE_DISPLAY appropriately, based on the data in NRLG_MILEPOINT.
If you are just wanting the data to be displayed differently in your select statement, you can convert the datatype in your SQL statement. Specifically how you would do this depends on the current datatype of NRLG_MILEPOINT.
Assuming that varchar2 is the type, based on the comments, here is an SQLFIDDLE link displaying a crude example of option 3. Your usage of this may vary depending on the actual datatype of NRLG_MILEPOINT. Regardless of its datatype... I am sure there is a means of converting how it is displayed in your query. You could take this further and create a view if you needed to. As an inline view or as a stored view, you can then use the converted value for doing your join later.
I live in Brasil and decimal separators are commas. For a bunch of reasons, I use dots as decimal separators in SQL Server, which is different from Excel.
With that being said, I would like to know why the following query
select 1.0*5
is understood as text in Excel (if so), when copying and pasting, and dots are not converted to commas, while
select cast(1.0*5 as float)
is understood as float in Excel.
What is the type of result in the first query?
UPDATE
If the query were
select 1.1*5
the result of copy and paste in Excel cell would be 5.5. It is not possible to convert this to value in Excel.
While the second query would result in 5,5. I can use the use this value in Excel in an addition operation, for example.
If you're doing it directly IN Excel, it seems that your regional settings are not seeing that as an operation with a decimal, but rather text. If you change your regional settings to US, it would probably resolve it correctly.
The difference between the two is that you are literally telling the value to be cast differently than the default. So your regional setting is overridden.
Excel, as smart as it is, tends to make many assumptions that could be tied to any number of things. Sometimes you just have to deal with it.
In the end, your 2nd query is likely to produce better results.
There is a problem in VBA text box while filling input mask property:
I am trying to make the combination of date and time:
Hence i put it like below:
00/00/00;0;_00:00;0;_
But while running the application, i am only getting 00/00/00 (Date).
But i remember, i got the result as like 00/00/00 00.00 as expected when i first put the expression as like above;
but now i am not getting it :-(
The InputMask property can contain up to three sections separated by semicolons (;)
Your mask should be like this:
"00/00/00 00:00;0;0"
or
"00/00/00 00:00;0;_" // to display it like __/__/__ __:__
Why not just use the built in "General Date" format? I've found over the years that input masks are very restricting and basically a pain. Although it's been so long since I've used them that I don't recall the details of why I despise them.
This also has the benefit of respecting the users choices of regional date format. For example I always use yyyy-mm-dd format.
Also a client had a situation where the date format was decreed to be Medium Date on all fields. Which is dd-mmm-yy. It later turned out that in a table of 100K records there were twelve dates before 1900. They had simple had something extra keyed in in the year so Windows/Access interpreted those dates as being in the 3rd or 5th century or whatever. Now these dates weren't used in any kind of calculation so it wasn't a big deal. SQL Server upsizing to small date/time fields didn't appreciate those though.