I need to be able to display a money field as $XX,XXX.XX, but without converting to varchar using total_eval = '$' + CONVERT(varchar(19),total_eval.opvValueMoney,1)
My project uses sorting of the information after I pull this to sort the column and it doesn't sort correctly when the column is a varchar.
Is there anyway to do this?
This is part of an ASP.NET system, but I have no access or control over after the information is returned.
Can you not format this when the data is being printed on the screen? Then the number remains a number and you can format is as you please at the presentation level.
For example, using PHP you could do something like this:
echo money_format('$%i', 3.4); // echos '$3.40'
// ^ here is your number, no formatting from the db!
This example was found in an answer to this question.
Related
I need help on how to resolve characters of unknown type from a database field into a readable format, because I need to overwrite this value on database level with another valid value (in the exact format the application stores it in) to automate system copy acitvities.
I have a proprietary application that also allows users to configure it in via the frontend. This configuration data gets stored in a table and the values of a configuration property are stored in a column of type "BLOB". For the here desired value, I provide a valid URL in the application frontend (like http://myserver:8080). However, what gets stored in the database is not readable (some square characters). I tried all sorts of conversion functions of HANA (HEX, binary), simple, and in a cascaded way (e.g. first to binary, then to varchar) to make it readable. Also, I tried it the other way around and make the value that I want to insert appear in the correct format (conversion to BLOL over hex or binary) but this does not work either. I copied the value to clipboard and compared it to all sorts of character set tables (although I am not sure if this can work at all).
My conversion tries look somewhat like this:
SELECT TO_ALPHANUM('') FROM DUMMY;
while the brackets would contain the characters in question. I cant even print them here.
How can one approach this and maybe find out the character set that is used by this application? I would be grateful for some more ideas.
What you have in your BLOB column is a series of bytes. As you mentioned, these bytes have been written by an application that uses an unknown character set.
In order to interpret those bytes correctly, you need to know the character set as this is literally the mapping of bytes to characters or character identifiers (e.g. code points in UTF).
Now, HANA doesn't come with a whole lot of options to work on LOB data in the first place and for C(haracter)LOB data most manipulations implicitly perform a conversion to a string data type.
So, what I would recommend is to write a custom application that is able to read out the BLOB bytes and perform the conversion in that custom app. Once successfully converted into a string you can store the data in a new NVCLOB field that keeps it in UTF-8 encoding.
You will have to know the character set in the first place, though. No way around that.
I assume you are on Oracle. You can convert BLOB to CLOB as described here.
http://www.dba-oracle.com/t_convert_blob_to_clob_script.htm
In case of your example try this query:
select UTL_RAW.CAST_TO_VARCHAR2(DBMS_LOB.SUBSTR(<your_blob_value)) from dual;
Obviously this only works for values below 32767 characters.
I'm working in Access 2010's SQL editor and I'm performing a calculation that results in a ratio.
I would like to display this ratio as a percentage using the SQL syntax editor, but as a number, not a string. I'd like to be able to paste out/export to Excel and not have to convert text to numbers.
Let's say this is my calculation:
OriginCount/DestinationCount AS MatchRate
I used the FORMAT function to make it appear as a percentage, but the result appears as a string. (Which I think is how the FORMAT function is designed to work)
FORMAT(OriginCount/DestinationCount,'Percent') AS MatchRate
Question 1: Is this possible using the SQL syntax editor?
Question 2: How do I do it?
Thanks!
How will you be using this data? It is standard to leave it as a double, EG: 0.02354, and then simply change the format of any control displaying that field.
Users should not being seeing tables or queries without them being the recordsource of a form, so this shouldn't be a problem.
That way, when exporting to Excel/Wherever else, it will properly display as a decimal number, and when viewing in Access, it will display as a Percentage 2.35%
The result of the FORMAT function in access is always in string format, so that would be expected behavior.
Did you try the CONVERT function instead?
https://msdn.microsoft.com/en-us/library/ms187928.aspx
What data type in SQL Server will insert the correct number of decimal places for the number entered into a table. When I try to enter a number like so 6.828.678 into a deciaml or numeric field it says input value was not in the correct format. What data type do i use so that it allows this?
If you are trying to store the data in format 6.828.678 (as in your post) then consider using VARCHAR data type.
You can't store 6.828.678 format data into either deciaml or numeric type field cause they are not valid number format and that's why you are getting the error.
Not sure, but per your comment if you want to SUM and compare the value then store it as INT datatype but before inserting the data make sure to remove the ..
You can use REPLACE() function like CAST(REPLACE('6.828.678','.','') as INT). Hope this helps.
I am loading data from Excels into database on SQL Server 2008. There is one column which is in nvarchar data type. This field contains the data as
Text text text text text text text text text text.
(ABC-2010-4091, ABC-2011-0586, ABC-2011-0587, ABC-2011-0604)
Text text text text text text text text text text.
(ABC-2011-0562, ABC-2011-0570, ABC-2011-0575, ABC-2011-0588)
so its text with many sentences of this kind.
For each row I need to get the data ABC-####-####, respectivelly I only need the last part. So e.g. for ABC-2010-4091 I need to obtain 4091. This number I will need to join to other table. I guess it would be enough to get the last parts of the format ABC-####-####, then I should be able to handle the request.
So the example of given above, the result should be 4091, 0586, 0587, 0604, 0562, 0570, 0575, 0588 in the row instead of the whole nvarchar value field.
Is this possible somehow? The text in the nvarchar field differ, but the text format (ABC-####-####) I want to work with is still the same. Only the count of characters for the last part may vary so its not only 4 numbers, but could be 5 or more.
What is the best approach to get these data? Should I parse it in SSIS or on the SQL server side with SQL Query? And how?
I am aware this is though task. I appreciate every help or advice how to deal with this. I have not tried anything yet as I do not know where to start. I read articles about SQL parsing, but I want to ask for best approach to deal with this task.
Stackoverflow is about programming.
Sit down and start programming.
Ok, seriously. That is string parsing and the last part in brackets with multiple fields means no bulk import, it is not a standard CSV file.
Either you use SSIS in SQL Server and program the parsing there or.... you write a program for that.
String maniupation in SQL is the worst part of the language and I would avoid it.
So, yes, sit down and program a routine. Probable the fastest way.
If I understand correctly, "ABS-####-####" will be the value coming through in the column and the numeric part is variable in length.
If that is the case, maybe this will work.
Use a "Derived Column" transformation.
Lets say we call "ABC-####-####" = Column1
SUBSTRING("Column1",(FINDSTRING("Column1","-",2)+1),LEN(Column1)-(FINDSTRING("Column1","-",2)))
If I am not mistaken, that should give you the last # values in a new column no matter how long that value is.
HTH
I have worked this problem out with the following guides:
Split Multi Value Column into Multiple Records &
Remove Multiple Spaces with Only One Space
I'm trying to load a file where are all the lines use the same rules. (assume HEADER is a single line)
HEADER1
HEADER2
.......
But unluckily when I try to use the LOAD DATA INFILE statement I get this error: Error Code: 1409
Can't load value from file with fixed size rows to variable.
This is the code I wrote:
USE test;
DROP TABLE IF EXISTS EXAMPLE_H;
CREATE TABLE EXAMPLE_H(
ID CHAR(20),
SP CHAR(3),
IVA CHAR(11) PRIMARY KEY,
NLP CHAR(6),
DLP DATE,
DUVI DATE,
DELP CHAR(30),
FILLER CHAR(39),
VTLP CHAR(3),
FILL CHAR(49)
);
LOAD DATA INFILE 'BTILSP.TXT'
INTO TABLE test.EXAMPLE_H
FIELDS TERMINATED BY ''
LINES TERMINATED BY '\n'
(ID, SP, IVA, NLP, #var_date_one, #var_date_two, DELP, FILLER, VTLP, FILL)
SET DLP = str_to_date(#var_date_one, '%Y%m%d',
DUVI = str_to_date(#var_date_two, '%Y%m%d');
I had this idea reading the bottom of this page (comment by Ramam Pullella), and I found the same explained on some websites, but I can't understand why I'm getting this error.
If I don't use the #var_date_one and #var_date_two variables, and so the STR_TO_DATE function, the date isn't rendered as MySql needs - the date in the file is something like "20100701" - then that field would contain all zeros or a different date than what I'm expecting. If I change DLP and DUVI to be represented by CHAR(8), then it works, but I won't use the SQL DATE comparisons and similar tools.
Can you help me please? :)
Thank you very much.
EDIT:
It seems the problem is given by the LINE TERMINATED BY '', since this kind of line is a "fixed row (undelimited)". Maybe it can't be assigned to variable for an unknown reason, but it's this way it works.
The documentation says:
User variables cannot be used when
loading data with fixed-row format
because user variables do not have a
display width.
Any suggestion?
RE-EDIT:
I've read the comment by Ryan Neve at bottom of that page. He gives a trick to read fixed-row into variables:
LOAD DATA LOCAL INFILE '<file name>' INTO TABLE <table>
(#var1)
SET Date=str_to_date(SUBSTR(#var1,3,10),'%m/%d/%Y'),
Time=SUBSTR(#var1,14,8),
WindVelocity=SUBSTR(#var1,26,5),
WindDirection=SUBSTR(#var1,33,3),
WindCompass=SUBSTR(#var1,38,3),
WindNorth=SUBSTR(#var1,43,6),
WindEast=SUBSTR(#var1,51,6),
WindSamples=SUBSTR(#var1,61,4);
Do you think it's a good way to do it? :)
I'm no expert, but it seems to me that if the fields are terminated by an empty string, then they have to be fixed size instead; there has to be some way to determine the boundaries between fields, and if there is no terminator, then they pretty much have to be fixed size.
I observe that the MySQL 5.5 manual says:
User variables cannot be used when loading data with fixed-row format because user variables do not have a display width.
It also (rather earlier on the page) says:
If the FIELDS TERMINATED BY and FIELDS ENCLOSED BY values are both empty (''), a fixed-row (nondelimited) format is used. With fixed-row format, no delimiters are used between fields (but you can still have a line terminator). Instead, column values are read and written using a field width wide enough to hold all values in the field. For TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT, the field widths are 4, 6, 8, 11, and 20, respectively, no matter what the declared display width is.
Since your statement has no 'FIELDS ENCLOSED BY' and empty 'FIELDS ENCLOSED BY', that is why you have a fixed format. And hence you cannot do as you want.
Sometimes, it is easier to massage the data outside the DBMS - fixing the data representation might be one such operation. I do have program that I call DBLDFMT that I've not used for a few years now, but it can do a variety of operations, such as convert decimal numbers with implicit decimal points (a mainframe trick; the price field might be 0023199, representing the value £231.99). It can deal with date manipulations too (not necessarily using a particularly user-friendly notation, but it is able to deal with the problems I faced getting data from mainframes into a Unix DBMS - not MySQL; it didn't exist when I wrote this code. Contact me if that might be of any interest - see my profile.
In case someone else comes across this.
If you just run
LOAD DATA LOCAL INFILE '<file name>' INTO TABLE <table>
(#var1)
SET ...
without specifying FIELDS TERMINATED BY, and your file contains commas MySQL will split on those by default.
In such case you can just tell MySQL that your field delimiter is something silly. eg:
FIELDS TERMINATED BY '############'
This way the whole line gets put in the first "column" ie your user variable. You can then use it exactly as shown in your code at the top.
It's worth noting MySQL treats delimiter a string, so you can even have
FIELDS TERMINATED BY 'this_string_thoes_not_appear_in_my_file
if you want