Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Slightly random one which has been bugging me for a while.
I am confused as to what actually makes a server a sever. I understand that a web-sever like Apache 'serves' web pages to the client. Why then is an SQL database server also called as such. What behaviours do the two entities have in common that make both of them servers? Or is it simply a case of same word - different meaning.
Appreciate any light shedding
Thanks
Dear Why we used "server" keyword in general scenario.
Server means, it serve the service.
So this keyword is associate because both are given service.
Sqlserver :- it store the actual data and give response as data to application response, comes from application which is hosted on application server. In sqlserver we can get/set the from various way like direct query of select/insert/update, via stored procedure, via application , used for SSIS, SSRS, SSAS services too.
Apache web server :- It is Web server, means a location where your application is actually hosted. It is used "WEB" keyword means it is used for web technologies and web application is hosted on that.
Both are different in terms of service, but give service or response as request comes, that why we called server.
An apache web server "serves" web pages to the client. An SQL database server "serves" databases to client applications. Applications need databases to store and extract data from, and a server provides them with exactly that.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Our firm has a rather complex proprietary Access database system including 15 or so unique front end modules that all perform different tasks and a backend database for each of our clients. All of these front end modules and backend databases have many SQL queries, functions, macros, and VBA code. We are considering upgrading to SQL Server or an equivalent but I see several major pitfalls including the incompatibility with VBA and Access functions. Do you think it would make more sense to stay with Access and look into improving via 1. accde/mde or accdr/mdr 2. split databases and/or 3. merging/consolidating front end modules? Do some of you have experience with such an upgrade or have any other recommendations?
You should consider migrating tables to SQL Server and keeping the Access Front-end. SSMA For Access will move the data and replace the tables with ODBC linked tables for you.
Then, moving forward, you can continue to use Access or build applications using other tools.
It is assumed that you run front ends with linked tables to the back end accDB file.
You then can migrate that database to sql server, you migrate only the data part.
The access FE (front end) should work as before - about 99% of the code and forms will work as before, but some tweaks are often required. Given that SQL express is free, then it is great setup and will allow you to keep and preserve most of your existing software investment
However, on each workstation, you are placing a FE of the application on that workstation. You as a general rule can't allow multiple users into the same given FE - it is to be placed on each workstation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Would it be possible to set up a SQL server as follows?
User enters a special URL in the browser
URL connects to a SQL server and calls a Stored Procedure (or Function)
Stored Procedure delivers HTML text as a result
No pictures are needed. Everything we need could be embedded in one single HTML.
EDIT:
The core idea of this question is to go without a separate web server. However, I don't want to re-create a full-blown web server with SQL server. My main idea is only that users could pull a HTML report directly from SQL server, without the need to take all the hassle and install a dedicated web server for this.
So technically, the core of my question is if there exists a special kind of URL which could call a stored procedure directly? Or if you can setup the SQL server in a way that it listens to some special URL calls?
EDIT 2:
Possibly, if SQL server could internally host a kind of "mini web server", that could also help.
Generally it is not possible without web server.
While you can output some html from stored procedure - SQL server itself lacks ability to listen for http requests and produce http responses.
In fact, dealing with http requests/responses is what web server intended to do - so there is no any reason for sql server to handle this.
In SQL Server 2005 something like this was possible through special web endpoints. This was horribly insecure and the feature was deprecated in the later versions of SQL Server.
For current versions of SQL Server you will need some web server and some sort of middleware (asp/asp.net/php/node.js) which will make the connection on behalf of the client. As an alternative you can use SSRS (reporting service) which uses IIS as a web server to run your site.
With SSRS:
User enters a special URL in the browser
Enters something like http://127.0.0.1/Reports/Pages/Report.aspx?ItemPath=%2fsome%2fname`
URL connects to a SQL server and calls a Stored Procedure (or Function)
Report connects to database and gets result.
Stored Procedure delivers HTML text as a result
Stored procedure returns plain result set. But you can generate report in MHTML format.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am looking for an alternative to SQL Server Agent jobs - there is a need to control running and scheduling of processes (executables, "jobs") and so I intend to implement a Windows Service that will act as a scheduler for these processes.
These processes are not interactive, so there is no problem starting them from a Windows Service, but they need to work with SQL Server - reading and writing data, executing stored procedures etc.
Commands to windows service ("scheduler") - like "enqueue a job" - would be passed from SQL Server CLR in UDF or directly from a client side web app via WCF (haven't decided yet).
Is this a right way to do this? Are there any access and security issues should I be aware of? I am particulary worried about possible limitations on processes run from a windows service.
Please share your experiences with similar designs.
Also, I consider using SQL Server Service Broker (suggested in similar thread) but I am not sure if it fits my needs.
Thank you!
Adam
The right way to achieve a reasonable security level is:
create a new user that will run the Windows Service (you can create this user in Control Panel)
create a new login for this user in SQL Server (using Integrated Security)
give the necessary, but minimum, permissions to this user in SQL Server
To implement a service you must be aware of a few things:
if you use WCF (or any other service stack), you need a thread for listening the requests and a different thread to run the processes in SQL server. If not, the subsequent requests will probably time out. (You can launch new threads for each task, or implement a queue to avoid overloading the server).
be extremely careful with error (exception) handling. If an unhandled exception is thrown your service will stop, until someone starts it again
it's harder to implement the UDF solution, becasuse you need to modify SQL Server security settings to allow an UDF to communicate with the "outer world"
you should include some kind of logging in your service, so that you can test it and verify it's working correctly.
It's not to hard to make an executable that can be run as console app as well as as a service. If you do so you can run it from the Visual Studio debugger, or stand alone, and log in the console (Console.Write...(...)), to see what's going on.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am trying to create a log in page for my application. Since there are multiple users, my page will have the ability to store user names and password. I am using VS2012, being that I am new to programming, I am not sure if using Access or SQL Server. If I create the database to store the log in info, when I compile the program how would that affect the user who installs the program. Would the database "go with the program" when compiled?
I can also use Access to store the data, but I have the a similar issue. If the user's computer does not have Access installed on their PC, how would the table be accessed?
This is probably an entry level question, I have done some research on this but have not found much information.
If you store the login information in a Sql Server Database then you need to install the SqlServer on the customer PC and distribute your database file with your application. It is not an easy task to do in a setup project and probably this is a possible motive for Microsoft to develop the LocalDB version of Sql Server that is a little bit more easy to install.
In the case of Access you need to distribute the MDB file (your database) and (if you stay with the 2003 version) nothing else because all the required libraries are distributed together with the NET framework. In case you want to use the ACCDB file format then you need to install on the customer PC the Microsoft Access Database Engine. However in Access you could find problems with 32bit and 64bit version of the OS. It is advisable to use always the x86 as target platform.
There are also alternatives like SQLite and Sql Compact Edition.
In these days, I would use the cloud. Make your program a webapplication and use an SQL database. Then the program would be accessible in any location where there's access to an internet connection. This means that it can be used on Windows, Mac's, Linux, tablets, smartphones and even smart tv's (Not that anyone uses that).
There's good tutorials on how to do this for a webapplication from PHPacademy. See:
http://www.youtube.com/watch?v=9kyQGBABA38&list=PLE134D877783367C7
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm working on a large SQL Server database with no documentation. Is there a good, preferably free, documentation generator tool I can use to get my head around it.
One tool that I'm using more and more to do this sort of thing is LinqPad (www.linqpad.net). This is far more than just a Linq tool. It is very good at allowing you to drill down through table relationships, as long as FK's are properly in place. This tool is free.
On the non-free side, we also use Red-Gates SQL Doc (http://www.red-gate.com/products/sql-development/sql-doc/). Excellent tool.
You might want to have a look at my new (non-free, sorry) tool - LiveDoco - it's a web app that can be installed on an intranet IIS or even on a local IIS server and then you can just use your favorite browser to connect to a SQL Server database and see its structure/metadata, edit object descriptions or even search in DB object names (tables, columns, functions and their parameters etc.) and in the extended properties where the descriptions are usually stored (under “MS_Description”). And finally there is an export feature you can use to export all extended properties to a SQL file that you can run on a different DB of the same/similar structure to import/update your descriptions/notes there.
There is a fully functional (but read-only) online demo at http://www.livedoco.com.
This link will take you directly to the Person.Contact.ContactID column in the AdventureWorks sample DB from MS: http://demo.livedoco.com/livedoco/Explorer?Server=(local)%5Csql2k8xpress&Database=AdventureWorks#/?L0Name=Person&L1Name=Contact&L2Name=COLUMN_ContactID