What is the correct syntax when creating a table in Access with SQL? I have tried DECIMAL, DOUBLE, NUMBER, INT... nothing lets me create an integer category with limiters.
Example:
CREATE TABLE NONGAME (
ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY,
DESCRIPTION CHAR(30),
ON_HAND NUMBER(4), <------- DOES NOT WORK!
CATEGORY CHAR(3),
PRICE DECIMAL(6,2), <------- DOES NOT WORK!
ANYTHING DOUBLE(4,2) <------- DOES NOT WORK!
);
MICROSOFT ACCESS DATA TYPES
The following table shows the Microsoft Access data types, data types used to create tables, and ODBC SQL data types. Some types have limitations, outlined following the table.
Microsoft Access data type Data type (CREATE TABLE) ODBC SQL data type
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
BIGBINARY[1] LONGBINARY SQL_LONGVARBINARY
BINARY BINARY SQL_BINARY
BIT BIT SQL_BIT
COUNTER COUNTER SQL_INTEGER
CURRENCY CURRENCY SQL_NUMERIC
DATE/TIME DATETIME SQL_TIMESTAMP
GUID GUID SQL_GUID
LONG BINARY LONGBINARY SQL_LONGVARBINARY
LONG TEXT LONGTEXT SQL_LONGVARCHAR[2]
MEMO LONGTEXT SQL_LONGVARCHAR[2]
NUMBER (FieldSize= SINGLE) SINGLE SQL_REAL
NUMBER (FieldSize= DOUBLE) DOUBLE SQL_DOUBLE
NUMBER (FieldSize= BYTE) UNSIGNED BYTE SQL_TINYINT
NUMBER (FieldSize= INTEGER) SHORT SQL_SMALLINT
NUMBER (FieldSize= LONG INTEGER) LONG SQL_INTEGER
NUMERIC NUMERIC SQL_NUMERIC
OLE LONGBINARY SQL_LONGVARBINARY
TEXT VARCHAR SQL_VARCHAR[1]
ARBINARY VARBINARY SQL_VARBINARY
[1] Access 4.0 applications only. Max 4000 B. Behaviour similar to LONGBINARY.
[2] ANSI applications only.
[3] Unicode and Access 4.0 applications only.
Note: SQLGetTypeInfo returns ODBC data types. It will not return all Microsoft Access data types if more than one Microsoft Access type is mapped to the same ODBC SQL data type. All conversions in Appendix D of the ODBC Programmer's Reference are supported for the SQL data types listed in the previous table.
Limitations on Microsoft Access data types
BINARY**, **VARBINARY**, and **VARCHAR: Creating a BINARY, VARBINARY, or VARCHAR column of zero or unspecified length actually returns a 510-byte column.
BYTE: Even though a Microsoft Access NUMBER field with a FieldSize equal to BYTE is unsigned, a negative number can be inserted into the field when using the Microsoft Access driver.
CHAR**, **LONGVARCHAR**, and **VARCHAR: A character string literal can contain any ANSI character (1-255 decimal). Use two consecutive single quotation marks ('') to represent one single quotation mark ('). Procedures should be used to pass character data when using any special character in a character data type column.
DATE: Date values must be either delimited according to the ODBC canonical date format or delimited by the datetime delimiter (#). Otherwise, Microsoft Access will treat the value as an arithmetic expression and will not raise a warning or error.
For example, the date "March 5, 1996" must be represented as {d '1996-03-05'} or #03/05/1996#; otherwise, if only 03/05/1993 is submitted, Microsoft Access will evaluate this as 3 ÷ 5 ÷ 1996. This value rounds up to the integer 0, and since the zero day maps to 1899-12-31, this is the date used.
A pipe character (|) cannot be used in a date value, even if enclosed in back quotes.
GUID: Data type limited to Microsoft Access 4.0.
NUMERIC: Data type limited to Microsoft Access 4.0.
(More information at the Source)
Limitations on ODBC Desktop Driver data types
The Microsoft ODBC Desktop Database Drivers impose the following limitations on data types:
All data types Type conversion failures might result in the affected column being set to NULL.
BINARY Creating a zero-length BINARY column actually returns a 255-byte BINARY column.
DATE The DATE data type cannot be converted to another data type (or itself) by the CONVERT function.
DECIMAL (Exact Numeric)** Not supported.
Floating-Point Data Types The number of decimal places in a floating-point number may be limited by the number format set in the International section of the Windows Control Panel.
NUMERIC Supports maximum precision and a scale of 28.
TIMESTAMP The TIMESTAMP data type cannot be converted to itself by the CONVERT function.
TINYINT: TINYINT values are always unsigned.
Zero-Length Strings: When a dBASE, Microsoft Excel, Paradox, or Textdriver is used, inserting a zero-length string into a column actually inserts a NULL instead.
(Source)
More Information:
MSDN : Create and Delete Tables and Indexes Using Access SQL
MSDN : CREATE TABLE Statement (Microsoft Access SQL)
Microsoft Docs : Microsoft Access Data Types
Microsoft Docs : Data Type Limitations
Microsoft Docs : Converting between ODBC and SQL Server data types
Microsoft Docs : Limitations of SQL ODBC Desktop Drivers
Wikipedia : Open Database Connectivity (ODBC)
Small addendum by Erik:
You can actually use the Decimal data type in CREATE TABLE queries. However, this requires your statement to be executed either using ADO, or on a database that's been set to use ANSI-92 compatible syntax.
To set your database to ANSI-92 compatible syntax:
Go to File -> Options. Open the tab Object Designers. Go to Query Designer, and under SQL Server Compatible Syntax (ANSI 92), check This Database. Now you can just execute the query. Note that this affects all queries in the database, and affects queries in various ways.
To execute a query using ADO:
In the VBA Immediate Window, execute the following line:
CurrentProject.Connection.Execute "CREATE TABLE NONGAME (ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY, PRICE DECIMAL(6,2));"
Of course, you can execute more complex queries using ADO.
DECIMAL and DOUBLE cannot be used in Access. For a "price", CURRENCY is the best bet. For my other integer, I just used NUMBER and gave it no limiters.
Related
I am saving the output of my AnyLogic model into an SQL server database. For non-AnyLogic aficionados, AnyLogic is based on Java. However, I am not sure what data types I need to specify for my columns in the database.
So far I am using these:
double in AnyLogic : float in SQL
string in AnyLogic : varchar in SQL
int in AnyLogic : int in SQL
I also have parameters that are of type Option list, which is, if I understand correctly, a form of Java enum. I tried to save those parameters as varchar, but this (obviously) does not work. In addition, my model contains various boolean parameters. For my boolean parameters, I add columns of type bit in SQL by running:
ALTER TABLE myTable
ADD my_bool BIT NOT NULL DEFAULT 0;
However, running the model returns this error
SQLServerException: Invalid column name 'false'. Caused by: Invalid column name 'false'
So concretely, how can I export parameters of type Option list and boolean?
This addresses the original question which was tagged MySQL.
I don't know all the issues around "option list". Seems like a string (with a length such as varchar(255)) would work. You can also look into the built-in enum type, although I would not normally recommend using enums.
I would recommend using boolean instead of bit as the equivalent for boolean. Seems more mnemonic.
That said, MySQL understands false as a constant. You can check this by running:
select false
This also works:
select "false"
However, this returns the error that you specify:
select `false`
I suspect that the code being generated is using this construct. You will need to look at the code -- and you might need to figure out some other way of handling this. In MySQL you can use 0 for false and that might fix your problem.
The AnyLogic database is a standard HSQLDB database (not something proprietary) but they've added AnyLogic client functionality to define 'column types' as though they are Java types (with special types for option lists and compiled-on-the-fly-and-run Java code).
If you look at the db.script file (HSQLDB just stores the persistent DB data as an SQL script which creates the tables and INSERTs the values) you can see the underlying HSQLDB types which map closely to SQL Server types.
boolean --> BOOLEAN
double --> DOUBLE
int --> INT
String --> VARCHAR(16777216)
Date --> TIMESTAMP
Code --> VARCHAR(16777216)
Option List --> VARCHAR(255)
NB: The 'Java column types' are supposed to make it easier for a non-technical user to understand what they will get from a Java perspective when querying that column but, for example, they are confusing in that queries will return Java nulls for missing values, so a boolean column actually effectively returns a Boolean.
That should help.
I managed to address part of my problem. I am now able to store String variables from Java into my SQL database. The issue was due to incorrect use of quotations.
Java uses double quotations for String variables (e.g.: ""). SQL expects single quotations (e.g.: '') for string-like columns such as varchar() and char()
I had to amend my SQL query to this:
String insertTableSQL = "INSERT INTO test (my_string) VALUES(" +" '"+my_variable_string+"' )";
Note that my_variable_string is a derivative of a Java enum, which I obtained by executing String my_variable_string= my_enum.name();
I created database with
DB2_COMPATIBILITY_VECTOR = ORA
it should include NUMBER_COMPAT and VARCHAR2_COMPAT set to ON
http://goo.gl/tHSDM8
But when I try to create table with number column like NUMBER(38) it says that number is too long.
It is also case with definition of variable in pl/sql package - varchar2(32767).
Thank you in advance
There are certain differences in how these data types are supported between Oracle database and DB2 -- they are clearly explained in the documentation.
NUMBER(x) maps to the DECIMAL(x) data type, for which the maximum precision is 31. If you need more, use DECFLOAT(34).
The maximum size of VARCHAR data type (for which VARCHAR2 is just a synonym) is 32672 bytes.
We use DB2 as our main production database, but we use SQL Server for many other things i.e. to do integration between other customers and vendors via EDI etc.
I have a table in SQL with SO numbers and I try to make a lookup in DB2 to get all the invoices for the SO's in my table, so here's what I did.
Created a connection to the DB2 using the Microsoft® OLEDB Provider for DB2
Created a data fllow with a source using a SQL Server connection.
Added a Data Conversion Transformation trying to convert the INT so value to a decimal with a precision of 12, but I couldn't change a precision in a DT_DECIMAL, so the only datatype that I have the option to change the precision is DT_NUMERIC.
Added a lookup transformation to lookup the data withing DB2.
Now when i try to create the join between the source table and DB2 I get an error Cannot map the input column, 'so', to the lookup column, 'orno', because the data types do not match.
According to Microsoft this is not a bug and they suggest to use the DT_NUMERIC where you can change the precision.
If I try to convert the SO to a DT_DECIMAL without changing the precision I'd get the same error mentioned above.
Is there any way to work around the limitations from SSIS and change the precision in a DT_DECIMAL conversion so I could do the match?
Or any other suggestions?
The simple answer is to change the connection property in the DB2 connection to treat DECIMAL as NUMERIC.
See bellow
I want to add a column to my EMP_2 table. The new EMP_PCT column will store a percentage as a number, for example 20% as 20.0.
I tried to input this method. But it gave a syntax error in the ALTER TABLE statement.
Why is it not working? Below is the SQL I am using:
ALTER TABLE EMP_2
ADD EMP_PCT NUMBER(4,2);
Access DDL data type names can be challenging to sort out. NUMBER actually creates a field as double precision float. But if you try to include field size, precision, or scale in parentheses after NUMBER, you will get a syntax error. The following statement creates a double field whether you execute it from ADO or DAO:
ALTER TABLE MyTable ADD COLUMN EMP_PCT NUMBER;
The next statement adds a decimal data type column to MyTable with precision = 4 and scale = 2, which means it will hold up to 2 digits to the left of the decimal point and 2 to the right.
CurrentProject.Connection.Execute "ALTER TABLE MyTable ADD COLUMN EMP_PCT DECIMAL (4,2);"
I used CurrentProject.Connection to execute the DDL statement because it is an ADO object, and Access SQL only allows you to create a decimal field with ADO. The statement will trigger a syntax error if you attempt to execute it from DAO, like with CurrentDb.Execute or from the Access query designer. See Field type reference - names and values for DDL, DAO, and ADOX for more information.
As #ErikE explained, Access' decimal type is problematic, especially with Access 2003 which you're using. Consider whether you might be able to use a currency type field instead. It avoids decimal buginess and offers faster performance due to the way the db engine handles the fixed number of decimal places.
First, I recommend that you not use the Decimal data type in Access 2003 because there are bugs with it around sorting (wrong order) and aggregating (sums truncating the fractional portion). In Access 2007 the aggregate problem is solved but not the sorting (though you can supposedly fix this in Access 2007 by putting an index on the column).
As for your script, there are two obvious problems:
You must use ADD COLUMN ColumnName not ADD ColumnName
The correct data type is DECIMAL, because NUMBER creates a double-precision float instead, and doesn't allow parentheses after it specifying any kind of size. (Maybe NUMERIC would work as a synonym of DECIMAL but I don't know.)
So this should work for you:
ALTER TABLE EMP_2 ADD COLUMN EMP_PCT DECIMAL(4,2);
According to HansUp and other sources, this cannot be submitted through DAO (as in CurrentDb.Execute) but must be done via ADO (CurrentProject.Connection.Execute).
Apparently, there is a way to get this SQL working but it requires a database settings change:
The decimal data type isn't supported in the default Jet 4.0 mdb file. You have to use the SQL Server compatibility syntax (ANSI 92) setting to use the decimal data type in the SQL Window.
Click on the menu, Tools > Options. Click on the Tables/Query tab. Mark the check box for "This database" in the SQL Server compatibility syntax (ANSI 92) section. This mode will affect the entire db, including queries with wildcards, so you may want to try this on a copy of your db.
If you still cannot get things working, you might consider this method (thanks to Philippe Grondier):
Dim TD As DAO.TableDef
Dim F As DAO.Field
Set TD = CurrentDb.TableDefs("TableName")
Set F = TD.CreateField("FieldName", dbDecimal, 4)
F.DecimalPlaces = 2
F.DefaultValue = 0
TD.Fields.Append F
For reference, here are some related Microsoft.com help pages:
Access 2003 ALTER TABLE statement
Access 2003 SQL Data Types
try this
ALTER TABLE EMP_2 ADD (EMP_PCT NUMBER (4,2));
try this,
ALTER TABLE EMP_2
ADD COLUMN EMP_PCT NUMBER(4,2);
Or else try using this URL,
AddingFields
When I upsize from Access2007 to SQL Server 2008, I have few issues...
1. text to nvarchar(255)
fields with text data type in Access are automatically converted to nvarchar(255)(I have unicode data) in sql server, but in reality the column-length is not that big so can I change the data type to nvarchar(55) or varchar(100)? Will there be any problem?
2. Date stored as text
Some tables throwed an error when tried to upsize because of the date column(mm/dd/yyyy), what I did is I changed the date/time column data type to text datatype in access, then the upsizing was successful, it converted to nvarchar(255) in sql server. I have converted nvarchar data type to date data type in sql server, but that does not show me a calendar symbol in access front-end. How to get a calendar symbol in the date field in my access front end?
I have tried the solution given in this link, but it did not work... Please give me some suggestions
text in sql server is deprecated, use nvarchar if you need to store unicode (multi lang support). Otherwise you can use varchar.