I have some txt files that contain tables with a mix of different records on them which have diferent types of values and definitons for columns. I was thinking of importing it into a table and running a query to separate the different record types since a identifier to this is listed in the first column. Is there a way to change the value type of a column in a query? since it will be a pain to treat all of them as text. If you have any other suggestions on how to solve this please let me know as well.
Here is an example of tables for 2 record types provided by the website where I got the data from
create table dbo.PUBACC_A2
(
Record_Type char(2) null,
unique_system_identifier numeric(9,0) not null,
ULS_File_Number char(14) null,
EBF_Number varchar(30) null,
spectrum_manager_leasing char(1) null,
defacto_transfer_leasing char(1) null,
new_spectrum_leasing char(1) null,
spectrum_subleasing char(1) null,
xfer_control_lessee char(1) null,
revision_spectrum_lease char(1) null,
assignment_spectrum_lease char(1) null,
pfr_status char(1) null
)
go
create table dbo.PUBACC_AC
(
record_type char(2) null,
unique_system_identifier numeric(9,0) not null,
uls_file_number char(14) null,
ebf_number varchar(30) null,
call_sign char(10) null,
aircraft_count int null,
type_of_carrier char(1) null,
portable_indicator char(1) null,
fleet_indicator char(1) null,
n_number char(10) null
)
Yes, you can do what you want. In ms access you can use any VBA functions and with some
IIF(FirstColumn="value1", CDate(SecondColumn), NULL) as DateValue,
IIF(FirstColumn="value2", CDec(SecondColumn), NULL) as DecimalValue,
IIF(FirstColumn="value3", CStr(SecondColumn), NULL) as StringValue
You can use all/any of the above in your SELECT.
EDIT:
From your comments it seems that you want to split them into different tables - importing as text should not be a problem in that case.
a)
After you import and get it in the initial table, create the proper table manually setting you can INSERT into the proper table.
b)
You could even do a make table query, but it might be faster to create it manually. If you do a make table query you have to be sure that you have casted the data into proper type in your select.
EDIT2:
As you updated the question showing the structure it becomes obvious that my suggestion above will not help directly.
If this is one time process you can follow HLGEM's solution. Here are some more details.
1) Import into a table with two columns - RecordType char(2), Rest memo
2) Now you can split the data (make two queries that select based on RecordType) and re-export the data (to be able to use access' import wizard)
3) Now you have two text files with proper structure which can be easily imported
I did this in my last job. You start with a staging table that has one column or two coulmns if your identifier is always the same length.
Then using the record identifier, you move the data to another set of staging tables, one for each type of record you have. This will be in columns for the data and can have the correct data types. Then you do any data cleaning you need to do. Then you insert into the real production table.
If you have a column defined as text, because it has both alphas and numbers, you'll only be able to query it as if it were text. Once you've separated out the different "types" of data into their own tables, you should be able to change the schema definition. Please comment here if I'm misunderstanding what you're trying to do.
Related
CREATE TABLE Persons(
ID int not null,
Name varchar(255) not null,
Description varchar(255));
INSERT INTO Persons values(15, "Alex", [["cool",1,19],["strong", 1, 20]]);
Is it possible to use a list of lists in this case or should I use another type?
Consider how you will query this data in the future. For example, will you need to search for a person with a specific trait in their description? How would you write that query if it's stored in a "list" as you call it? Using any kind of semi-structured data makes it easy to put data in, but it's not always clear how to search the data afterwards. You should think ahead with this in mind.
If you use the technique of structuring your database into Normal Forms, you will end up with a database that is the most flexible in terms of supporting a wide variety of queries.
Any standard Relational DMBS is not supposed to store such data as it violates normalisation principles.
While the following schema will suffice to create a table it saves a little time now and creates massive time sink later.
CREATE TABLE Persons
(
ID int not null,
Name varchar(255) not null,
MultiValueColumnViolates1NF varchar(255)
)
;
It violates the 1st NF because column MultiValueColumnViolates1NF allows multiple data tuples in a single cell. Yes, it can hold a list (JSON or XML depends on the RDBMS flavour). Or as normal DBAs call this: Garbage in, garbage out. Or as I call it: Excel tables.
An actual design to store such data preferably is at least in 2NF. Which in this case can be:
CREATE TABLE People
(
Name varchar(255) not null,
SingleValueColumn varchar(255)
)
;
The INSERT statement will then allow inserting data like:
INSERT INTO People
VALUES
( 'Alex', '["cool",1,19]' ),
( 'Alex', '["strong", 1, 20]')
;
One issue: No unique key possible. So there are multiple rows coming back if data is retrieved for 'Alex'.
Probably not what you want to achieve.
An RDMBS performant way to store this data is in two separate tables.
CREATE TABLE People
(
ID int not null,
Name varchar(255) not null
)
;
CREATE TABLE People_Data
(
ID_People int NOT NULL,
Key varchar(100) NOT NULL,
Value varchar(200) NOT NULL
)
;
The downside to data normalisation is that it makes it more difficult to get the data back (Murphys Law: A database stores data and is unwilling to show it back once it has hold of the data).
If this is just to store data in a database that is completely used outside the database forever and a day then go with the first table creation.
If not, please use normalisation to allow fast and efficient analysis of the data through database tools.
I stumbled upon this definition:
CREATE TABLE dbo.whatever (
[flBlahBlah] BIT DEFAULT ((0)) NOT NULL,
[txCity] NVARCHAR (50) DEFAULT ('') NOT NULL,
[cdFrom] VARCHAR (10) DEFAULT ('') NOT NULL
);
I can't think of a reason to add those default values. Not null string is defaulted to '' and bit is defaulted to 0. Is there a reason for defining these default values? Am I missing something? Is this in some best practice handbook I'm not aware of?
I'd just use:
CREATE TABLE dbo.whatever (
[flBlahBlah] BIT NOT NULL,
[txCity] NVARCHAR (50) NOT NULL,
[cdFrom] VARCHAR (10) NOT NULL
);
The database is in MS SQL Server 2012, now migrating to Azure Database.
For example you create table from a first batch of your question. Then insert value like this
INSERT INTO dbo.whatever (flBlahBlah) VALUES (1)
You will get 1 row dbo.whatever
flBlahBlah txCity cdFrom
1
So if you "forget" to insert in one of the column with default values determined - SQL Server will take care of them.
It is very useful when you got table, in which you need to insert new field. With default value determined you don't need to change SP/query's/other stuff that works with this table.
I am new to MSSQL 2014 Server, my professor listed these steps to make a table, I don't know the proper steps to create tables in the pictures listed below, please help.
Create and populate (insert values) the following tables per table description and data values provided
DEPARTMENT
EMPLOYEE
PROJECT
ASSIGNMENT
Add a SQL Comment to include /* * Your First Name_Your Last Name* */ when inserting corresponding values for each table.
What I tried so far:
CREATE TABLE DEPARTMENT(
DepartmentName Text(35) PRIMARY KEY,
BudgetCode Text(30) NOT NULL,
OfficeNumber Text(15) NOT NULL,
Phone Text(12) NOT NULL, );
I have put this to my query and the error is
Msg 2716, Level 16, State 1, Line 1 Column, parameter, or variable #1: Cannot specify a column width on data type text.
Try this(I assume that your table exists in dbo schema):
IF OBJECT_ID(N'dbo.DEPARTMENT', N'U') IS NOT NULL
BEGIN
DROP TABLE DEPARTMENT
END
GO
CREATE TABLE DEPARTMENT(
DepartmentName varchar(35) PRIMARY KEY,
BudgetCode varchar(30) NOT NULL,
OfficeNumber varchar(15) NOT NULL,
Phone varchar(12) NOT NULL
);
You can not define width for Text data type. In case which you need to define width you can use char or varchar data types. Also keep in mind that if you need to work with Unicode characters then you will need to use nchar or nvarchar instead.
Why can I not use a variable to name a new table?
As a beginning SQL project, I'm making a personal finance database. Each account will have a corresponding table in the database. There is also a table listing all the current accounts. See (simplified) code sample below:
CREATE TABLE accountList
(
[Id] INT NOT NULL PRIMARY KEY IDENTITY,
[Name] NCHAR(30) NOT NULL UNIQUE,
[Active] BIT NOT NULL
)
INSERT INTO accountList(name, active)
VALUES
('Bank_One_Checking', 1);
CREATE TABLE Bank_One_Checking
(
[Id] BIGINT NOT NULL PRIMARY KEY IDENTITY,
[payee] NCHAR(30) NOT NULL UNIQUE,
[category] NCHAR(30) NOT NULL UNIQUE,
[amount] INT NOT NULL DEFAULT 0.00
)
This code works. I want to set the account name to a variable (so it can be passed as a parameter to a stored procedure). See code below:
DECLARE #accountName nchar(30);
SET #accountName = 'Bank_One_Savings';
INSERT INTO accountList(name, active)
VALUES
(#accountName, 1);
CREATE TABLE #accountName
(
[Id] BIGINT NOT NULL PRIMARY KEY IDENTITY,
[payee] NCHAR(30) NOT NULL UNIQUE,
[category] NCHAR(30) NOT NULL UNIQUE,
[amount] INT NOT NULL DEFAULT 0.00
)
Line 6 in that code (CREATE TABLE #accountName) produces an error
Incorrect syntax near #accountName, expecting '.', 'ID', or 'QUOTEID'.
Why won't it insert the variable into the command?
SQL doesn't allow tables to be variables. You could use dynamic SQL, if you like, but I strongly recommend against it.
Your code has several flaws. You should learn not only to fix them but why they are wrong.
You need a "master" table, where AccountName is a column. Multiple tables with the same structure is almost always a sign of poor database design.
Strings should be designed using VARCHAR() or NVARCHAR(), unless they are short or known to be the same length (say an account number that is always 15 characters). Fixed-length strings just waste space.
I find it unlikely that a column named category would be unique in such a table. It seems to violate what uniqueness means.
Integers are not appropriate for monetary amounts in most of the world (use decimal or money). And, they shouldn't be initialized to constants with a decimal point.
I want to create a table named Domains in HSQL. But when i try to do so it includes 29 columns although my table definition specifies just 5.There is a Domains System View and it seems it is including these columns also in my metadata.Because of this i am not able to insert anything in my db as those unwanted columns from Domains System View also contain some non-null values.
I tried creating schema but it is not what i need as my solution.
I need to override this Domains System View or stop the metadata from picking it.
Does anyone know how can we do it?
I am stuck at it for more than few days now.
CREATE TABLE IF NOT EXISTS Domains
(
domain_id INTEGER NOT NULL,
name VARCHAR(100) NOT NULL,
description VARCHAR(500) NOT NULL,
CREATED_BY VARCHAR(8) NOT NULL,
LAST_UPDATED_BY VARCHAR(8) NOT NULL,
PRIMARY KEY (domain_id)
);