we are currently investigating a migration of an application that doesn't meet company standards. The application is built using VB6 and Shape SQL/Access. The application has about 120 reports by storing Shape SQL strings in a database which the user can modify using a wizard.
Shape sql is not allowed at this company. We have investigated plain SQL, Linq, Entity Framework as alternatives... but all result in more complex solutions.
Does anyone have another suggestion?
Update: Shape SQL is an ADO command to get hierarchical datasets, for further info: http://support.microsoft.com/kb/189657
I know you said SHAPE is not allowed, but you could still use SHAPE against SQL Server through an ADO connection if you could get that criteria relaxed in the face of more difficult alternative implementations.
Have you looked at the XML features in SQL Server 2005 and up?
Hierarchical result sets are not typical relational database features, but you can do a lot with XML.
Have a look at this article, too
We have been in contact with Microsoft (in the Netherlands), their solution for now is to use Linq as a replacement. They also have contacted MSFT to get some responses, I will update my answer when we get more information.
Related
We're upgrading our systems to support clustering and auto failover features. Our business runs .NET 4 applications, web apps and services on SQL Server Express. We can upgrade to SQL Server Standard, but the cost has motivated us to consider other options. Is it a legitimate option to integrate our .NET data layer with ODP.NET? After searching, I have seen a tendentious statement or two in the negative (viz) and yet it would seem that people are doing it anyway. What development features in the Visual Studio IDE will we lose? Thanks for your help!
Well, I'm now working since 20+ years with Oracle and MS SQL Server, having done a lot of projects. Some projects are running now more than 10 years, with all the updates, maintenance and so on.
My quick answer is: Stay with MS SQL Server. Go to Oracle only, if you have really GOOD TECHNICAL reason, or if you are planning really an ENORMOUS database, and if you have enough staff to handle all thge administration.
The main reason is that SQL Server is much easier to maintain; and it also integrates greatly into the Microsoft environment.
Oracle, in contrast, has a steep learning curve. The handling of Oracle is much more "manual" then MS SQL Server. Well, that's also a good thing, because you are in control of every small detail, but it also means that you need to learn a lot; or you need to pay experts. And it is not so easy to find people who really know what to do.
I really like both Systems, but for a rule of thumb, I normally suggest to use MS SQL Server.
I've been using .net with Oracle for years, and migrate away from it whenever the option is available.
If all your database code is in stored procs and you call it though the codebehind or a library and you use ansi sql your migration from ms sql to oracle will be fairly painless.
If you use TableAdapters, they re-write any sql you put in to the oldschool oracle 8 syntax like table1,table2,table3 then have a big where clause to do the join conditions. There's also some weird bugs where sometimes sql that runs fine over in SQL Developer won't work in the TableAdapters.
If you use Entity Framework migration should be pretty easy, but the MS SQL driver is much better then the Oracle one. There have been several queries I couldn't do though EF in oracle because of some of the various errors with the current driver.
If you need more info let me know.
Also if Cost is the main reason to consider migration, why not go with mysql?
Since you are already working in MS SQL, you must be habitual of the way it work, be it entity framework or any other data execution. Yes offcource, microsoft has very high license rates for it. But if you want to move to any other database, it is perfectly alright. I have personally used MS SQL and MySQL both. Initially you might face some syntax related issues, but do remember that logic remains the same for fetching and saving the data. Further it gives a benefit that you got to learn a new language and that too at the expense of far less money.
I am creating a ASP.NET application that is pretty much self contained, it will be pushed to different hosts and as a result will include an embedded database engine - I did look at SQLite but that can not run under medium trust and that could be an issue, so it looks like it is going to have to be Microsoft SQL Server Compact Edition 4.
Microsoft SQL Server Compact Edition does not support stored procedures and because of such I'm wondering where the best place to include the SQL code would be, taking into account future edits, etc.
So far I think that my options are either directly embedded in the code as a String or Stringbuilder type (which can get messy for advanced queries), or maybe in SQL files stored in the App_GlobalResources folder - the second option is something something that I have only just considered, but think that that would be a pretty good option for containment and future editing - does anyone have any other suggestions?
Regards, Nathan.
You can store parameterized queries in your resource file.
You can use MS SQL Express. It is free, it has stored procedures, but it has 4GB database size limit (increased to 10 GB for SQL Server Express 2008 R2).
For more information read this.
I think it's better to use some ORM tool or LINQ to SQL, than store native SQL strings.
Like other have said an ORM, Entity Framework or Linq to SQL is probably better than inline SQL, however as your question wasn't asking about any of these I would suggest storing you SQL files as embedded resources. Others have mentioned resource resource files but I feel that resource files are difficult to use and you do not have an nice IDE to develop within. Having embedded .SQL files should be easier to version control, use within Visual Studio, allow you to keep your queries as closely as possible to your data access components and make it difficult to change once in a production environment.
I've been looking into a lot of database's recently, and am not sure if it's because I'm bored or what, but I want to create a few web applications using database's other than MS SQL Server. Any suggestions that tie into ASP.NET nicely?
I'd recommend VistaDB and MySql.
I'd consider MySQL as the obvious alternative.
However, fundamentally one relational database is pretty much the same as another, more so when accessed through something like ADO.NET. If you're bored with SQL Server then rather than looking for an alternative why not look at trying different data access strategies?
You don't mention whether or not you're using an ORM (object relational mapper) which can make working with databases a lot more enjoyable than using standard ADO.NET, such as:
NHibernate
Entity Framework
Linq to SQL
Subsonic
IMO, sticking with SQL Server but trying out a few different ORM's would be much more interesting than switching to a different database altogether.
Or how about looking into using a document database, such as RavenDB?
I suggest you take a look at Connectionstrings.com. Most databases there have a .NET provider available.
Define "good".
Do you want to have a database as a simple data store, or should the database also implement business logic (stored procedures, triggers)?
Do you want to ship your apps and therefore require easy of installation?
Does it matter if the database is commercial, when MSSQL offers a free version?
As #richeym pointed out: are SQL statement a sufficient interface, or do you require an ORM?
I need to extract Quickbooks SQL structure to make a Diagram about the tables that I need to work with. Could this be possible ?
I think QODC could solve my connection issue but I don't know how to extract SQL dump from it.
Thanks in advance
You can't directly access the QuickBooks SQL structure, so you're out of luck. Most versions of QuickBooks are not even based on an SQL backend (only Enterprise edition is), so it's not even applicable to those versions.
QuickBooks provides an XML-based API to adding/modifying/querying/deleting data within it, but does not provide direct SQL access. QODBC is a wrapper around the XML-based API which simply transforms XML requests into SQL requests, and vice versa. It is not reverse-engineering anything, it's simply transforming data from one format/protocol, into another.
You choices are to either use the XML API as is, use QODBC, or use the XML API and do something similar to what QODBC is doing by transforming the XML into an SQL-friendly format. I've done something similar with my PHP code, schema and code linked below:
MySQL Schema
QuickBooks PHP Framework
You can install QODBC, then setup a linked table in Sql Server Mgmt Studio.
From there, you can more or less query the tables out of QuickBooks into tables in a SQL Svr database.
With QuickBooks Enterprise 2011 this changed, and you can have real ODBC access (although with limited rights and to a limited amount of tables) and then use an SQL tool to map via the ODBC access.
QODBC publishes data layouts for all of the tables it exposes here. The format is really nice if you want to correlate a field on the QuickBooks screen to a table, which is usually what you need in a QuickBooks integration design process.
The company I work for has decided to join the 21st century and upgrade our main database cluster from SQL Server 7 to SQL Server 2005. As a web developer what new whiz-bang features of SQL Server 2005 should I get excited about or get to know?
Currently I'm mainly writing CRUD style queries, pretty much exclusively using Stored Procdures for a mixed ASP.net and Classic ASP environment.
system tables are now inaccessible, you will need use the system catalog views. Yes, some of your code needs to be rewrited.
partitioning. You can split very big table into two.
Try..Catch.
Common table expressions (CTE). It's like temporary tables, but more powerful.
Management server, that helps you to register your server groups and then use these groups from any another client place. (maybe it is in 2008 only? I cannot remember)
I don't know about your needs, but I was excited by mirroring. But I'm DBA :)
Some new types.
Snapshots.
Most of your code will still work :)
and many another things.
One that comes to mind is that you can integrate CLR / .NET code into SQL Server.
Here are some others.
My favorite new features are
varchar(max) nvarchar(max) data types
(much easier to work with than text,
ntext)
xml data type and Xpath support
Improved error handling with try...catch blocks
.NET code integration
Improved management interface
Common table expressions, PIVOT and UNPIVOT, APPLY
SQL 7? I'd start with the basics, like referential integrity and cascades. Or, you don't have to code your own triggers for all that stuff that Access was doing back in 98 or so when one had Sql 7.
Performance monitoring, profiling, tuning
Dynamic Management Views & Functions
http://msdn.microsoft.com/en-us/library/cc917696.aspx