We have HANA database with SPS 12.
We have requirement where we need to format decimal as per business rule -
Typically I want comma as thousand separator as -
Input - 12345678.1234
Ouput - 1,23,45,678.12
In Oracle, it is possible with to_char(input,'99,99,99,999.99').
Is it possible to achieve same in HANA?
What you're asking sounds as if the format shall be used for client presentation of the number values. If that is the case, please use the data formatting options of the client tools you use.
The example you mentioned is actually doing two things: formatting the number by your specification and changing the data type to char. That means you cannot use it for further calculations.
Usually, with Oracle tools you would define the output formatting in the client tool (e.g. SQL*PLUS has the option to define formatting with the COLUMN setting).
The standard SAP HANA SQL clients like hdbsql or SAP HANA Studio take the formatting settings mainly from the OS environment and don't provide specific options to change the formatting.
For SAP HANA Studio I wrote a detailed explanation on what factors drive the formatting of dates and numbers, see here.
Related
What do you avoid when creating and filling out a Excel spreadsheet of data for a SQL database (certain formats, characters, character length issues?)
2.Does it matter how dates are formatted?
VARCHAR or INTEGER errors you've seen?
Finally, what SQL or Python queries did you use to address errors you found that you might have shared for questions 1-3?
The easiest way would be, if you can import Database-EDI (e.g. Oracle SQL Developer) a TXT- or CSV-Excel-Export into our Database.
→ Depending on the database, different requirements must be observed.
The main focus is on the correct formatting with regard to the country settings (Excel & database):
Excel-Format-Date YYYY-M-DD HH24:MM / Databe-Timestamp YYYY-MM-DD HH24:MM:SS.FFFF
→ That would not work
In addition, make sure that Excel does not cut any numbers:
Excel-Format-Long-Number 89632150000 (orignal 896321512345 )
→ Excel automatically shortens the number in the standard settings.
The length of a text must not exceed the specified maximum length in the assigned column of the type (VARCHAR).
I think these would be the main points to look out for.
By default, my ASP.NET project creates a table with the decimal column with "," delimeter. All decimals are stored in format "100,10". How can I change the delimeter to "."?
It causes problems with jQuery validation. JQuery thinks that it's not a number and the format of the field is wrong. I don't want to work around with jQuery.
All decimals are stored in format "100,10"
This misunderstands what is happening. Sql Server stores decimal values in a binary format that is not human readable.
What you are seeing is more likely formatting applied by your query tool, reporting platform, or chosen by the culture settings in the operating system or process on the client system after data is returned from the database.
You are confusing storage and representation.
SQL Server does not store "." or ",", it just stores a binary value.
The representation of decimal numbers in Visual Studio is controlled by your language settings in Windows.
The validation of jquery-validate (? you do not state which mechanism you are using) is controlled by configuration. See these answers, or the documentation of your library.
I'm trying to extract data (using SPUFI) from a DB2 table to a file, with one of the output fields converting a decimal field to the same format as a COBOL comp field.
So e.g. today's date (20141007) would be ..ëõ
The SQL HEX function converts 20141007 to 013353CF, and doing a SELECT of x'013353CF' gives me the desired result, but obviously that's a constant, I'm trying to find an equivalent function.
Basically an inverse of the HEX function.
I've come across a couple of suggestions using user defined functions. Problem is, we've only recently upgraded to DB2 10 and new function mode isn't enabled yet, which means I don't have access to any control functions in a UDF.
I suspect I'm out of luck, but wondering if anyone has any suggestions.
I appreciate this is completely the wrong tool for the job, and would be easier to just write a COBOL program to do it, but various constraints are preventing that. I'm limited to just SQL functions and possibly JCL).
I thought I had a solution using a recursive UDF to get around the lack of control functions, but that's not allowed either.
I am currently starting from scratch choosing a database to store data collected from a suite of web forms. Humans will be filling out these forms, and as they're susceptible to using international characters, especially those humans named José and François and أسامة and 布鲁斯, I wanted to start with a modern database platform that accepts all types (so to speak), without conversion.
Q: Does a databases exist, from the start, that accepts a wide diversity of the characters found in modern typefaces? If so, what are the drawbacks to a database that doesn't need to convert as much data in order to store that data?
// Anticipating two answers that I'm not looking for:
I found many answers to how someone could CONVERT (or encode) a special character, like é or a copyright symbol © into database-legal character set like © (for ©) so that a database can then accept it. This requires a conversion/translation layer to shuttle data into and out of the database. I know that has to happen on a level like the letter z is reducible to 1's and 0's, but I'm really talking about finding a human-readable database, one that doesn't need to translate.
I also see suggestions that people change the character encoding of their current database to one that accepts a wider range of characters. This is a good solution for someone who is carrying over a legacy system and wants to make it relevant to the wider range of characters that early computers, and the early web, didn't anticipate. I'm not starting with a legacy system. I'm looking for some modern database options.
Yes, there are databases that support large character sets. How to accomplish this is different from one database to another. For example:
In MS SQL Server you can use the nchar, nvarchar and ntext data types to store Unicode (UCS-2) text.
In MySQL you can choose UTF-8 as encoding for a table, so that it will be able to store Unicode text.
For any database that you consider using, you should look for Unicode support to see if can handle large character sets.
Now it generates inserts like
INSERT [Bla] ([id], [description], [name], [version])
VALUES (CAST(1 AS Numeric(19, 0)), convert(t...
It's very SQL Server specific. I would like to create a script that everybody can use, database agnostic. I have very simple data types - varchars, numbers, dates, bits(boolean).
I think
insert into bla values (1, 'die', '2001-01-01 11:11:11')
should work in all DBMSs, right?
Some basic rules:
Get rid of the square brackets. In your case they are not needed - not even in SQL Server. (At the same time make sure you never use reserved words or special characters in column or table names).
If you do need to use special characters or reserved words (which is not something I would recommend), then use the standard double quotes (e.g. "GROUP").
But remember that names are case sensitive then: my_table is the same as MY_TABLE but "my_table" is different to "MY_TABLE" according to the standard. Again this might vary between DBMS and their configuration.
The CAST operator is standard and works on most DBMS (although not all support casting in all possible combinations).
convert() is SQL Server specific and should be replaced with an approriate CAST expression.
Try to specify values in the correct data type, never rely on implicit data conversion (so do not use '1' for a number). Although I don't think casting a 1 to a numeric() should be needed.
Usually I also recommend to use ANSI literals (e.g. DATE '2011-03-14') for DATE/TIMESTAMP literals, but SQL Server does not support that. So it won't help you very much.
A quick glance at the Wikipedia article on SQL, will tell you a bit about standardisation of SQL across different implementations, such as MS SQL, PostgreSQL, Oracle etc.
In short, there is a number of ANSI standards but there is varying support for it throught each product.
The general way to support multiple database servers from your software product is to accept there are differences, code for them at the database level, and make your application able to call the same database access code irrespective of database server.
There are a number of problems with number formats which will not port between dbmses however this pales when you look at the problems with dates and date formats. For instance the default DATE format used in an ORACLE DB depends on the whims of whoever installed the software, you can use date conversion functions to get ORACLE to accept the common date formats - but these functions are ORACLE specific.
Besides how do you know the table and column names will be the same on the target DB?
If you are serious about this, really need to port data between hydrogenous DBMSes, and know a bit of perl thn try using SqlFairy which is available from CPAN. The sheer size of this download should be enough to convince you how complex this problem can be.