I'm trying to set up an SQL server for my web-server to send and receive data from. I'm somewhat confused on how the whole SQL server thing works though. I was wondering why I need a separate server for my SQL and my web server. why can't I save an SQL database on the server itself instead and access it the same way one would read and write an XML or JSON file on the server to store data?
You may be getting caught up with server, as in the computer its running on (physical box, virtual machine, might be easier to think of it as the operating system) vs the server, as in web server/sql server which are different software packages.
So the SQL server (software) and the Web server (software) can run on the same server (hardware, essentially).
Depending on your use case its usually best to have the SQL server on a different server (hardware) to your web server so that there is more dedicated resources for their processes, but its not required.
If you are asking why you cant talk to the database file directly, (in the case of MS SQL Server, at least) the server manages its own permissions and manages all the file IO for you. Its a bit more complicated than a JSON file.
Related
I have an Access DB which I connected to a SQL Server 2012 (v11.0.7507) as a linked server using Microsoft Office 12.0 Access Database Engine OLE DB Provider.
The connection is working fine usually but there are 2 automated jobs that push/pull data and update some other data in the Access DB either of which sometimes (not quite often but sometimes) gets "stuck" while connected to the Access DB. The session in SQL Server is visible but cannot be killed - or actually when I try to kill it it gets stuck in KILLED/ROLLBACK status.
No MSACCESS.EXE is open in tasklist, however the Administrative Tools' Open Files section does show the accdb (and the laccdb) files open by the SQL Agent. Unfortunately closing them there does not solve the problem, the accdb and laccdb files are still locked.
The only solution is restarting the SQL Server and then deleting the laccdb file but that is not a very comfortable solution.
I tried searching for similar issue but did not find a solution so far that would work. The main problem is the (seemingly) random nature.
Have you guys experienced something similar? Do you know what could be wrong with this setup?
Many thanks in advance.
The Access OleDb provider has very limited support in unattended applications, and should never be loaded in a long-lived application. See the note on the download site:
The Office System Drivers are only supported under certain scenarios,
including:
Desktop applications which read from and write to various files
formats including Microsoft Office Access, Microsoft Office Excel and
text files.
To transfer data between supported file formats and a
database repository, such as SQL Server. For example, to transfer data
from an Excel workbook into SQL Server using the SQL Server Import and
Export Wizard or SQL Server Integration Services (provided the SSIS
jobs run in the context of a logged-on user with a valid
HKEY_CURRENT_USER registry hive).
Try using a separate short-lived process instead of Linked Server. An SSIS package is a common choice.
I am new to SQL and to SQL server and I am using the book to build my knowledge. During early parts of the book, the author has below para. I am confused with the sentence in bold and italics below.
What is the purpose behind running multiple instances of SQL server on a given server? It seems that SQL server is a very costly software, in such case isn't installing multiple instances a costly task?
The Database Engine sits at the core of the SQL Server components. The engine operates as a service on a machine, which is often referred to as an instance of SQL Server. You can run multiple instances of SQL Server on a given server. When you connect to SQL Server, the instance is the target of the connection. Once an application is connected, it sends Transact-SQL (T-SQL) statements to the instance. The instance in return sends data back to the client. Within the connection is a security layer that validates access to the data as specified by the database administrators (DBAs). The Database Engine enables you to leverage the full capabilities of all of the other components, such as accessing, storing, and securing the data..
You might want to run various versions of SQL Server, e.g. 2008, 2008 R2 and 2012 simultaneously in parallel on a given machine. If you're e.g. a consultant and your clients use different versions of SQL Server, and you need to be able to get a backup from them, do some work, and send the database back, you have to use the same version as your client does. Backups aren't backwards-compatible, e.g. if your customer uses 2005, you can restore his 2005 backup onto your 2012 server, but you CANNOT return the data back to the client (since the backups are NOT backwards compatible - you cannot restore a 2012 backup on a 2005 server).
Or you might want to run separate instances for e.g. development and testing on the same physical server machine in separate instances (that are quite well isolated from one another). It's a great way to separate two (or more) "worlds" (environments) of SQL Server from one another; you might have all the same databases - but once in the "Development" context (for your dev team, work in progress), and a second time for your Quality Assurance or Testing team. If you have two totally separate instances, it's like having two (or more) servers living on one machine.
Multiple instances of SQL Server on a single physical machine are a great way to have separate environments - both based on the versions (and editions) of SQL Server you might need to support, but also in terms of the use of the instances - development vs. testing vs. demo vs. whatever-else-you-might-have.
Instances are very well protected from one another and don't interfere with each other - each has their own databases, logins, security, etc.
When writing an application that'll work with MS SQL database all we do is just we specify the connection parameters (either hard coded or dynamically). And when we install that application on a machine, we don't care if that machine has the proper tool to make the connection to the MS SQL Server database available.
However, in Oracle things are different. We have to make sure that all the machines that we want to install the app has Oracle Client set up. It will not work otherwise. Now my first question is what advantage does this provide? And the second one is if there's some way to achieve the similar in SQL Server?
Realistically, if Oracle owned Windows, the Oracle client would be installed with Windows and the SQL Server client would be a separate install. It's not a matter of advantages and disadvantages, it's a matter of who owns the stack and can bundle their software with the operating system.
Depending on exactly how you are building your Oracle application, there is a good chance that you can use the Oracle Instant Client or the Oracle thin (type 4) JDBC driver to provide connectivity to the database. Either of these can be installed by your application without requiring a separate Oracle client install.
I want to deploy my SQL Server 2008 Database with application on the client's machine, where i don't want that anybody can open and read or copy my Database Objects (i.e. Tables, SPs, Functions, Views etc.).
I want to protect database with password same like Microsoft Access 2007 When somebody opens it asks Password. Can it be done in SQL Server 2008, if yes how.?
SQL Server is not like Access and doesn't have any file-based password-protection mechanisms (in the "normal" editions like Web, Standard, Enterprise/Developer, Express).
SQL Server is a server-based product - you need to restrict physical access to the server the files are located on, and prevent unauthorized users from accessing the files through the SQL Server mechanisms (like logins and permissions).
If you need something like Access' password-protected files, you need to use SQL Server Compact Edition which is file-based and has a password-protect feature
An alternative approach that you may also wish to consider, that is in addition to deploying an initial secure instance configuration, is the Transparent Data Encryption feature in SQL Server. This way were someone able to access the database data files "outside" of SQL Server, i.e. via the file system, they would not be able to review the data without decrypting the data files.
I have a desktop application (C# .NET 3.5) that uses a SQL server for it's database. I have had a request from the client, however, to make it possible to export the database as it stands, and be able to use it on a laptop without connectivity. They understand that updates to the parent server will not be reflected in these offline clients.
Is there a way I can just save the DataSet's to a binary form and write them to a disk and send those files to the offline clients.
There is an entire line of tools and technologies covering this case, namely the Synch Framework. See Synchronizing Databases. See Getting Started: Client and Server Synchronization for a starting example involving a SQL Server Compact Edition file on the client (.SDF file) that is synchronized with a SQL Server central database. Note that the client won't install anything else other than you application, the SQL Server CE is just a few in-process DLLs that you distribute with your app, nothing nearly as complex as a SQL Express edition on the client.
The good news is that Synch Framework no only allows the client to get their own on-the-go snapshot of the database, it actually allows for changes applied while disconnected to be merged back into the central site.
You could either use Compact Edition (aka. SDF files), or you can save the datasets as XML using the built-in method.
Can't you just take a SQL Server level backup and have them install e.g. SQL Server Express on their laptops and restore the database there?
That way you wouldn't have to do anything special in your app at all - just change the connection string to point to the local SQL Server Express instance, and off you go! No mucking around with serialized data sets and stuff......