I want to store large files in SQL Server 2012. I have been suggested to use BLOB. All I want to do is to create a table which map the Employee id and the path of his image in database. Whenever user want to access the image he will get the path from the database first and then get the image from referenced database using BLOB.
Can you help me how to access different database from one database.
Generally speaking for large files (over 1 MB, but not a rule) you should use FILESTREAM (Overview) which stores the files on filesystem and not in the database itself.
See this article for a guide to set up using FILESTREAM in your database.
As for your question "Can you help me how to access different database from one database." Referencing objects in SQL is done with dot notation like this
databasename.schemaname.tablename
So you can use it to reference objects (tables) in different databases. For more info see Using Identifiers As Object Names not to reiterate what's there already.
Related
Problem:
I need to get data sets from CSV files into SQL Server Express (SSMS v17.6) as efficiently as possible. The data sets update daily into the same CSV files on my local hard drive. Currently using MS Access 2010 (v14.0) as a middleman to aggregate the CSV files into linked tables.
Using the solutions below, the data transfers perfectly into SQL Server and does exactly what I want. But I cannot figure out how to refresh/update/sync the data at the end of each day with the newly added CSV data without having to re-import the entire data set each time.
Solutions:
Upsizing Wizard in MS Access - This works best in transferring all the tables perfectly to SQL Server databases. I cannot figure out how to update the tables though without deleting and repeating the same steps each day. None of the solutions or links that I have tried have panned out.
SQL Server Import/Export Wizard - This works fine also in getting the data over to SSMS one time. But I also cannot figure out how to update/sync this data with the new tables. Another issue is that choosing Microsoft Access as the data source through this method requires a .mdb file. The latest MS Access file formats are .accdb files so I have to save the database in an older .mdb version in order to export it to SQL Server.
Constraints:
I have no loyalty towards MS Access. I really am just looking for the most efficient way to get these CSV files consistently into a format where I can perform SQL queries on them. From all I have read, MS Access seems like the best way to do that.
I also have limited coding knowledge so more advanced VBA/C++ solutions will probably go over my head.
TLDR:
Trying to get several different daily updating local CSV files into a program where I can run SQL queries on them without having to do a full delete and re-import each day. Currently using MS Access 2010 to SQL Server Express (SSMS v17.6) which fulfills my needs, but does not update daily with the new data without re-importing everything.
Thank you!
You can use a staging table strategy to solve this problem.
When it's time to perform the daily update, import all of the data into one or more staging tables. Execute SQL statement to insert rows that exist in the imported data but not in the base data into the base data; similarly, delete rows from the base data that don't exist in the imported data; similarly, update base data rows that have changed values in the imported data.
Use your data dependencies to determine in which order tables should be modified.
I would run all deletes first, then inserts, and finally all updates.
This should be a fun challenge!
EDIT
You said:
I need to get data sets from CSV files into SQL Server Express (SSMS
v17.6) as efficiently as possible.
The most efficient way to put data into SQL Server tables is using SQL Bulk Copy. This can be implemented from the command line, an SSIS job, or through ADO.Net via any .Net language.
You state:
But I cannot figure out how to refresh/update/sync the data at the end
of each day with the newly added CSV data without having to re-import
the entire data set each time.
It seems you have two choices:
Toss the old data and replace it with the new data
Modify the old data so that it comes into alignment with the new data
In order to do number 1 above, you'd simply replace all the existing data with the new data, which you've already said you don't want to do, or at least you don't think you can do this efficiently. In order to do number 2 above, you have to compare the old data with the new data. In order to compare two sets of data, both sets of data have to be accessible wherever the comparison is to take place. So, you could perform the comparison in SQL Server, but the new data will need to be loaded into the database for comparison purposes. You can then purge the staging table after the process completes.
In thinking further about your issue, it seems the underlying issue is:
I really am just looking for the most efficient way to get these CSV
files consistently into a format where I can perform SQL queries on
them.
There exist applications built specifically to allow you to query this type of data.
You may want to have a look at Log Parser Lizard or Splunk. These are great tools for querying and digging into data hidden inside flat data files.
An Append Query is able to incrementally add additional new records to an existing table. However the question is whether your starting point data set (CSV) is just new records or whether that data set includes records already in the table.
This is a classic dilemma that needs to be managed in the Append Query set up.
If the CSV includes prior records - then you have to establish the 'new records' data sub set inside the CSV and append just those. For instance if you have a sequencing field then you can use a > logic from the existing table max. If that is not there then one would need to do a NOT compare of the table data with the csv data to identify which csv records are not already in the table.
You state you seek something 'more efficient' - but in truth there is nothing more efficient than a wholesale delete of all records and write of all records. Most of the time one can't do that - but if you can I would just stick with it.
Say my code looks like this:
create database name1 on (name = N'name2', filename = N'C:\SQL\name3')
name3 I understand.
Now, 'name2' is supposed to be the "logical name". From what I can find, this means that this is the appropriate name to refer to this database in database engine. However USE name2, returns an error. In contrast, USE name1 works just fine.
The best answer I could find was here, but it was closed before the answer could be clarified (what would be an example where I would use it rather than name1?).
My question: What is the purpose of name2? When would I ever need to use it over name 1? Why is it a required component for file_spec?
Thanks. (SQL Server 2008 R2)
A database can reside in multiple files, for example:
CREATE DATABASE DatabaseName
ON (NAME='LogicalName1', FILENAME='C:\SQL\PhysicalName1.mdf'),
(NAME='LogicalName2', FILENAME='C:\SQL\PhysicalName2.mdf')
GO
USE DatabaseName
SELECT * FROM sys.database_files
In the above example, you can see that in addition to the two data files specified, a transaction log file was also created. This file has a different role than the data files (it records every change in the database, so it can be rolled-back if the transaction is not completed).
If you use multiple data files (in the same filegroup), they are both filled proportionally and this is useful for performance, if they are stored on separate disks.
If you use multiple data files in separate filegroups, you can specify the location of each table (and index), so you are able to place a table that is accessed more frequently on a separate, high-performance (and high-cost) disk.
See https://technet.microsoft.com/en-us/library/ms187087.aspx for details.
As Gordon already said, the logical file name is used in the ALTER DATABASE statement, when you need to refer to a particular file. Using this command, you may change the size of the file, the auto-growth settings or put a particular file offline. Also, you can move the file to another physical location. See https://msdn.microsoft.com/en-us/library/bb522469.aspx
I have a table named Reports which has 3 fields ID (auto number), filename (string field), theFile (attachment field).
What I want to is to run a SQL query and insert a PDF file into the attachments field (theFile).
Lets say the PDF file is located in the C: drive (C:\report1.pdf), I have tried the SQL query below but it is not working. I know its not good practice to store files in a database but I just want to try it out:
CurrentDb.Execute "INSERT INTO Reports (filename,theFile) VALUES ('report1'," & C:\report1.pdf & ")"
It's standard practice to store files in a database. Access certainly supports it, but not through SQL. You'll have to use DAO, as detailed at http://msdn.microsoft.com/en-us/library/office/bb258184%28v=office.12%29.aspx
"File" is not appropriate SQL data type supported in Access, available data types.
That is correct Derek, if you try to run a SQL statement like that you will get an error message of one type or another every time. I spent a fair amount of time researching this subject for my own DB, and from what I understand there are a number of options/alternatives; however, having an attachment column type and using SQL to insert a file is not an option with Access' current capabilities.
It is not bad practice to store files in a database, it is actually standard practice; however, it IS best practice to not store files in an ACCESS db. There are a few reasons for this which you can research on your own, but perhaps most notably, Access has a file size limit of 2GB, so if you store files in it you can run out of space quickly and then things get even more complicated.
Here are your options:
Change your column data type to OLE object and use some kind of stream reader to convert the files to binary data, then use a SQL statement to load them into your DB
Use the built in Access user interface for working directly with tables/attachments
Establish a DAO db connection and use Access' recordset.LoadFromFile function
Just store links to the files in the Access DB
The 4th option is the preferred method. It's very simple and you won't have to worry about complex code or the 2GB storage limit.
I have a bunch of xml files that is about 700 GB in size.
I'm going to load the data within those files into a SQL Server 2008 database table(tabular data).
In addition to the fields that will hold the data in a tabular format, the table will contain a field of SQL Server XML type that holds the xml data as a whole.
I want to use the FILESTREAM feature of SQL Server 2008 instead of loading the whole xml into the field.
I want to know the benefits the performance of the queries that will be made on such a very large-table will gain and the pros and cons of this feature.
Thank you in advance.
I do not expect this will ever be marked as the answer because the true answer will only be discovered after an through study of available solutions.
BUT
The answer I have is really a question for you. How are you going to use this data? IF your are going to shread the xml to retrieve the reporting values and keep the complete xml for a reference then I would goto Filestream. If you are going to run reports directly from the xml then you will have to load the data into the database creating the needed indexes.
Loading all data into SQL Server as a combination of shreaded xml and an xml datatype
PRO
All data is avaiable all the time from one source
A single backup contains all data
Additional data from XML can be shreaded to enhance reports on server side
CON
- Backup size
- Backup time
- Slow if data is in native XML
Loading values from XML into SQL Server and using Filestream
PRO
Data source (filestream) is tied to data values
Source data can be presented to client
Con
Filestream content is not available directly from within query
Filestream and SQL backups to syncronize for disaster recovery
Be aware of your storage needs for backups and the maintenaince window need.
I've been writing a Library management Java app lately, and, up until now, the main Library database is stored in a .txt file which was later converted to ArrayList in Java for creating and editing the database and saving the alterations back to the .txt file again. A very primitive method indeed. Hence, having heard on SQL later on, I'm considering to port my preexisting .txt database to mySQL. Since I've absolutely no idea how SQL and specifically mySQL works, except for the fact that it can interact with Java code. Can you suggest me any books/websites to visit/buy? Will the book Head First with SQL ever help? especially when using Java code to interact with the SQL database? It should be mentioned that I'm already comfortable with using 3rd Party APIs.
View from 30,000 feet:
First, you'll need to figure out how to represent the text file data using the appropriate SQL tables and fields. Here is a good overview of the different SQL data types. If your data represents a single Library record, then you'll only need to create 1 table. This is definitely the simplest way to do it, as conversion will be able to work line-by-line. If the records contain a LOT of data duplication, the most appropriate approach is to create multiple tables so that your database doesn't duplicate data. You would then link these tables together using IDs.
When you've decided how to split up the data, you create a MySQL database, and within that database, you create the tables (a database is just something that holds multiple tables). Connecting to your MySQL server with the console and creating a database and tables is described in this MySQL tutorial.
Once you've got the database created, you'll need to write the code to access the database. The link from OMG Ponies shows how to use JDBC in the simplest way to connect to your database. You then use that connection to create Statement object, execute a query to insert, update, select or delete data. If you're selecting data, you get a ResultSet back and can view the data. Here's a tutorial for using JDBC to select and use data from a ResultSet.
Your first code should probably be a Java utility that reads the text file and inserts all the data into the database. Once you have the data in place, you'll be able to update the main program to read from the database instead of the file.
Know that the connection between a program and a SQL database is through a 'connection program'. You write an instruction in an SQL statement, say
Select * from Customer order by name;
and then set up to retrieve data one record at a time. Or in the other direction, you write
Insert into Customer (name, addr, ...) values (x, y, ...);
and either replace x, y, ... with actual values or bind them to the connection according to the interface.
With this understanding you should be able to read pretty much any book or JDBC API description and get started.