I need to be able to write a script to create a table in Microsoft Access, and I am running into a problem. I need a long integer field (longer than LONG), so I have to use DECIMAL. The problem I am running into is it is defaulting the Format to scientific notation. I need it to stay as a normal integer value.
Here is my script:
CREATE TABLE MY_TABLE
(
MY_GUID GUID CONSTRAINT MY_CONSTRAINT PRIMARY KEY,
MY_NAME VARCHAR,
CREATOR VARCHAR,
MILLI_CREATED DECIMAL (13, 0)
);
The MILLI_CREATED field defaults to General Number Format, which then displays the value in scientific notation, like this: 1.444255960009E+12
How can I set the Format of the table during CREATE or with an ALTER or even at INSERT if that is what I have to do?
Related
Situation
My data is stored on a PostgreSQL server on my network. I've linked an ODBC data source to create linked tables to my data. The table in concern is one that is designed to track classes and their session details - including attendance. The table's design is so:
CREATE TABLE ClassSession
(
id integer NOT NULL DEFAULT nextval('"seq_ClassSession_id"'::regclass),
teacher_id integer NOT NULL,
class_name character varying(50) NOT NULL,
clients_in_attendance integer[],
date_of_session date DEFAULT CURRENT_DATE,
CONSTRAINT "ClassSession_pkey" PRIMARY KEY (id)
)
Problem
MS Access interprets integer[] data types as Short Text (pictured below). This isn't really a big deal as long as I can match the correct format of integer enclosed in { and } - with each being separated by a ,. An example would be: {12,34,56,67,78}.
Integer arrays as Short Text in Access - design view
Query example of Access interpreting integer arrays as short text/format
Question
I was looking for some direction on how to design a form in Access that can insert data into this table while restricted to this format (using the {, }, and , in plaintext) without having the user type the brackets, each number, and comma to separate the client_id values. Is anyone able to help?
I have a table with a column nif which has to be exactly 9 digits long, after I tried to do:
CREATE TABLE fornecedor(
nif numeric(9) PRIMARY KEY,
nome varchar(64) NOT NULL,
CONSTRAINT nif_tamanho CHECK (length(to_char(nif, 'FM999MI')) = 9));
INSERT INTO fornecedor(nif, nome) VALUES (123456789, 'Pmsmm');
It returns an error saying:
ERROR: new row for relation "fornecedor" violates check constraint "nif_tamanho"
How do I make it so that the inserted number is verified having 9 digits exactly ?
Thanks in advance
As you mention in your comment, you need a string data type if you don't want to lose leading zeroes.
But I think that the correct solution depends on how you want to use the column. It is always good to choose the data type according to the column's semantics.
If you need to do arithmetic or numeric comparisons with the data, choose integer by all means (you can add a check constraint on nif < 100000000). You can always format the value with leading zeroes when you convert it to a string for output.
If you need to do string operations on the value (e.g. substrings), storing the data as a sting type is preferable.
I am trying to create a SQL table in Netbeans 8.0 with one of its columns meant to store a byte[] (so VARBINARY is the type I am looking for). The wizard for the creation of a new table offers me the option of VARCHAR FOR BIT DATA, which should work, but it raises a syntax error when creating the table:
create table "BANK".Accounts
(
id NUMERIC not null,
pin VARCHAR FOR BIT DATA not null,
primary key(id)
)
The error is due to the presence of the word FOR, so I manually change the statement so that it is
create table "BANK".Accounts
(
id NUMERIC not null,
pin "VARCHAR FOR BIT DATA" not null,
primary key(id)
)
but now the problem is that the type does not exist. Any ideas?
Thank you.
Here's the manual page for VARCHAR FOR BIT DATA: http://db.apache.org/derby/docs/10.10/ref/rrefsqlj32714.html
Note the section that says:
Unlike the case for the CHAR FOR BIT DATA type, there is no default length for a VARCHAR FOR BIT DATA type. The maximum size of the length value is 32,672 bytes.
So the problem is that you haven't specified a length.
If your byte array is, say, 256 bytes long, you could specify
pin VARCHAR (256) FOR BIT DATA NOT NULL,
You might also consider using BLOB if that fits your requirements. You can see all the Derby data types here: http://db.apache.org/derby/docs/10.10/ref/crefsqlj31068.html
I am new to writing SQL and using Oracle... so I'm sorry if this is obvious but I can't figure it out. It's telling me that I'm missing a right parenthesis but as far as I can tell they are all there. It seems to be a problem with the VARBINARY line but I don't know why.
CREATE TABLE DATA_VALUE
(
DATA_ID VARCHAR2(40) NOT NULL,
POSITION INT NOT NULL,
VALUE VARCHAR2(50),
BINARY_VALUE VARBINARY(50),
DATA_TYPE VARCHAR2(20),
CONSTRAINT DATA_VALUE_PK PRIMARY KEY(DATA_ID, POSITION)
);
VARBINARY is not an Oracle data type. A quick search suggests MySQL and SQL Server have it, at least, but not Oracle. Perhaps you need to explain what you want to store in that field. The closest I can think you might mean is RAW.
The valid built-in datatypes are listed in the documentation:
The RAW and LONG RAW data types store data that is not to be
explicitly converted by Oracle Database when moving data between
different systems. These data types are intended for binary data or
byte strings.
This Microsoft article suggests you should be using RAW as a replacement for VARBINARY too, at least for the size you're talking about.
CREATE TABLE DATA_VALUE
(
DATA_ID VARCHAR2(40) NOT NULL,
POSITION INT NOT NULL,
VALUE VARCHAR2(50),
BINARY_VALUE RAW(50),
DATA_TYPE VARCHAR2(20),
CONSTRAINT DATA_VALUE_PK PRIMARY KEY(DATA_ID, POSITION)
);
table DATA_VALUE created.
I'm messing around with SQLite for the first time by working through some of the SQLite documentation. In particular, I'm using Command Line Shell For SQLite and the SoupToNuts SQLite Tutorial on Sourceforge.
According to the SQLite datatype documentation, there are only 5 datatypes in SQLite. However, in the two tutorial documents above, I see where the authors use commands such as
create table tbl1(one varchar(10), two smallint);
create table t1 (t1key INTEGER PRIMARY KEY,data TEXT,num double,timeEnter DATE);
which contain datatypes that aren't listed by SQLite, yet these commands work just fine.
Additionally, when I ran .dump to see the SQL statements, these datatype specifications are preserved:
sqlite> CREATE TABLE Vulnerabilities (
...> VulnerabilityID unsigned smallint primary key,
...> VulnerabilityName varchar(10),
...> VulnerabilityDescription longtext);
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE Vulnerabilities (
VulnerabilityID unsigned smallint primary key,
VulnerabilityName varchar(10),
VulnerabilityDescription longtext);
COMMIT;
sqlite>
So, what gives? Does SQLite keep a reference for any datatype specified in the SQL yet converts it behind the scenes to one of its 5 datatypes? Or is there something else I'm missing?
SQLite uses dynamic typing.
SQLite will allow you to insert an integer into that VARCHAR(10) column.
SQLite will not complain if insert a string longer than 10 characters into that column.
As el.pescado mentions, SQLite has storage classes AKA "affinities".
If you attempt to insert a column belongs to a particular affinity, then SQLite will try to convert that value to match the affinity.
If the conversion doesn't work, the value is inserted as-is.
So while your more granular datatypes are saved (apparently) to the metadata table, they are not being used by SQLite.
There are not five datatypes, rather 5 datatype "classes" that "real" datatypes fall into. So that, TINYINT, SMALLINT and BIGINT are three different datatypes, but all belonging to the INTEGER storage class.