What exactly is MS SQL Server?

[Doomer]

Can I develop a database application using it or would I need to use another program for the front end?

I need to put together a stand alone app. Not necessarily using SQL Server. Any advise much appreciated.

 

[Zontor]

That is a broad question....

Yes, technically you *could* create a basic application using only SQL server and a Windows box....but it would be very basic and not terribly user friendly. You usually use a front end like C#, vb, asp, or a multitude of others with MS SQL Server. BTW: MS SQL server is a relational database as is MySQL, Oracle, Postgre, etc. Most of the "stronger" products (with the exception of some Oracle suites) expect you to use a "front end" made from another product.

FoxPro, Access, Delphi, FileMaker, etc. might be a better choice for a stand-alone app if your user base isn't too high (generally less than 50-60 users at the same time) and your record count won't be super high (> 10 million records). These products typically have a "built-in" development environment to build stand alone apps.

 

[boran]

isn access a single user DB ?

 

[NuclearNed]

MS SQL Server is the spawn of the devil, born and bred to take over your unsuspecting soul.

Its also a really useful database.

 

[EagleKeeper]

Originally posted by: boran
isn access a single user DB ?

The Access application is single user.

An Access DB (.MDB) can be accessed by mulitple applications concurrently.

 

[MrChad]

Originally posted by: NuclearNed
MS SQL Server is the spawn of the devil, born and bred to take over your unsuspecting soul.

Its also a really useful database.

From a developer's standpoint, SQL Server is a joy to work with.

 

[NuclearNed]

Originally posted by: MrChad

Originally posted by: NuclearNed
MS SQL Server is the spawn of the devil, born and bred to take over your unsuspecting soul.

Its also a really useful database.

From a developer's standpoint, SQL Server is a joy to work with.

I am a developer, and in spite of my original statement I'll have to agree with you. As it happens, I'm currently stuck on the latest in a series of problems that I'm having with a TSQL script, thus the negative comment.

 

[Doomer]

Thanks all. That clears it up. I'm an experienced Access developer but have never even looked at MS SQL Server, MySQL, Oracle, etc.

At one time, you could turn a Access DB into a stand alone app but I think this was quietly swept under the rug.

Are there any all in one DB developement tools that are relatively easy to get up to speed with? I should know all this but I've had my head buried in the sand for years, LOL.

 

[Zontor]

A lot of people are happy with FileMaker Pro....

 

[Zontor]

Originally posted by: NuclearNed

Originally posted by: MrChad

Originally posted by: NuclearNed
MS SQL Server is the spawn of the devil, born and bred to take over your unsuspecting soul.

Its also a really useful database.

From a developer's standpoint, SQL Server is a joy to work with.

I am a developer, and in spite of my original statement I'll have to agree with you. As it happens, I'm currently stuck on the latest in a series of problems that I'm having with a TSQL script, thus the negative comment.

I've worked with both Oracle and TSQL - what, in your case, is TSQL doing or not doing that is causing your issue? The issues I typically have to resolve are typically "how best to do this" and aren't really caused by SQL extension language issues...just curious.

 

[ahurtt]

Originally posted by: Doomer
Thanks all. That clears it up. I'm an experienced Access developer but have never even looked at MS SQL Server, MySQL, Oracle, etc.

At one time, you could turn a Access DB into a stand alone app but I think this was quietly swept under the rug.

Are there any all in one DB developement tools that are relatively easy to get up to speed with? I should know all this but I've had my head buried in the sand for years, LOL.

Access is something akin to a spreadsheet with a database engine sitting on top of it. Products like SQL Server, Oracle, DB2 and the like are true enterprise class RDMS's.

 

[Doomer]

Cool, another question. Can an app developed in Access be ported to MS SQL?

btw: I don't know what TSQL is.

 

[Mark R]

Can an app developed in Access be ported to MS SQL?

Generally, yes but not completely.

SQL server doesn't provide a front end - so no forms, for users to enter or review data and very limited presentation of reports.

However, it is possible to port the data over to SQL server, but use an access application to send and receive data from the SQL server. In this way, you can get the power and reliability of SQL server, yet still retain the access application so that users can remain familiar with it.

 

[beyonddc]

I played with MySQL before and using C++ as front end. It's pretty easy to setup and the C++ API to the MySQL is also very easy to use.

 

[Doomer]

Thanks Mark, I'll explore this possibility.

 

[Zontor]

Originally posted by: Doomer
Cool, another question. Can an app developed in Access be ported to MS SQL?

btw: I don't know what TSQL is.

Yes. See Mark R's notes...

TSQL = Transact SQL. SQL is the language that is used to query nearly any RDMS db's. It is, more or less a standard. Once you know SQL, you can, technically talk to nearly any database (in truth it can be a bit harder than that but this is the theory).

Various manufacturers added "extensions" or features to SQL (such as looping). They are not universal and usually apply only to that manufacturers product. TSQL is Microsoft's implementation of these extensions.

 

[Doomer]

Thanks Zontor. Now I'm wondering, is the SQL queries created within SQL Server or does the front end do this? I'm trying to visualize exactly what SQL Server does. I have it but haven't installed it yet.

Thanks

 

[Zontor]

Originally posted by: Doomer
Thanks Zontor. Now I'm wondering, is the SQL queries created within SQL Server or does the front end do this? I'm trying to visualize exactly what SQL Server does. I have it but haven't installed it yet.

Thanks

You may run "ad hoc" queries - this means the queries are passed via something like ADO (in the case of Microsoft) to the server. The server then returns the data.

You may also (preferred) created "Stored Procedures" or "Views" which reside upon the server and are called in code. These are preferable because they're faster and to some measure, pre-compiled.

 

[Doomer]

Thanks. Think I have some studying to do.

I've always wondered how google works it's magic. Do they use their own in house SW or something like Oracle or SQL Server?

 

[NuclearNed]

Originally posted by: Zontor

Originally posted by: NuclearNed

Originally posted by: MrChad

Originally posted by: NuclearNed
MS SQL Server is the spawn of the devil, born and bred to take over your unsuspecting soul.

Its also a really useful database.

From a developer's standpoint, SQL Server is a joy to work with.

I am a developer, and in spite of my original statement I'll have to agree with you. As it happens, I'm currently stuck on the latest in a series of problems that I'm having with a TSQL script, thus the negative comment.

I've worked with both Oracle and TSQL - what, in your case, is TSQL doing or not doing that is causing your issue? The issues I typically have to resolve are typically "how best to do this" and aren't really caused by SQL extension language issues...just curious.

I have to be able to have a UDF execute a mathematical formula that is stored in a string (there is another thread around here about this problem). The solution to this problem involves using the EXEC function to populate a temporary table. However, temporary tables cannot be used in UDF's. So I attempted to change the temporary table into an instance of the table data type, but EXEC cannot be used to populate one of these.

 

[Zontor]

I haven't played with UDF's in SQL 2000 too much but I believe you can use table variables with them (as opposed to temp tables).... I'll have to dig around and find your thread here....curious myself.

 

[NuclearNed]

Originally posted by: Zontor
I haven't played with UDF's in SQL 2000 too much but I believe you can use table variables with them (as opposed to temp tables).... I'll have to dig around and find your thread here....curious myself.

You can use table variables with UDF's, but that isn't the problem. The problem is that to evaluate the string formula "1 + 1 / 2", you have to use the EXEC function (or the equivalent system stored procedure, sp_executesql). As far as I can tell, EXEC or the SP are the only functions that will evaluate a string to find a mathematical result, but EXEC and the SP have exactly the same limitations.

To put the result of the EXEC call into a variable, you have to first insert the results of the EXEC call into a table (see the other thread for details about this). EXEC will only work with real tables, or temporary tables. Temporary tables cannot be used inside a UDF, so using them is automatically ruled out. EXEC can't be used to populate table variables, so table variables also can be ruled out. That leaves me with putting the result in a real "defined" table, which is not really desirable. So unless something magical happens, I don't have any options left.