dbGo or dbExpress for Delphi 2010 with Microsoft SQL Server - sql-server

I am migrating to Delphi 2010 and I am using Microsoft SQL 2000 (Planning on upgrading to SQL2008). I have been using BDE all along and wondering if I should use dbGo (ADO) or dbExpress with my future application. Can someone explain to me the pros and cons for using either one?
Thanks a lot.

I've recently had exactly the same dilemma, wondering whether to move away from ODBCExpress to ADO or dbExpress which are more supported out-of-the-box.
My decision was very simple in the end, as it was made for me: dbExpress is uni-directional, designed for executing queries, not for cursor-style movement through a dataset. You have to add extra support in order to use grids and other db-aware controls, by using the TDataSetProvider and TClientDataSet components. So it can be done but the extra layers ruled it out for me.
Zarko Gajic has an excellent article on it on his delphi.about.com site.
I'm sure others will disagree and that's good, I welcome the discussion.

For performance reason and future development I will go with dbExpress.
dbExpress has been pushed up since latest version, but dbGo didn't changed since Delphi 5 or 6, and it's include just few fixing with each version, while dbExpress has been getting more improvment with each versions specially in last few releases.
another options is to use SDAC from DevArt, it's has the best performance and has more advanced features for Sql server compared to other technologies.

For simple applications J's soltution might be good enough, but for client / server applications where performance is an issue I'd go for dbExpress. The article by Zarko pointed out before is indeed good reading material.

Related

Applications similar to Oracle Forms

I want to design a (web) interface where I can view, modify, insert records into my database along with many other features like use another table as reference. Basically like Oracle Forms & Reports.
What other apps have similar functionality?
I also want to know how frequently do enterprises use Oracle Forms - the application as well as the functionality provided in Oracle Application Express.
As far as I can tell, people usually switch from Forms to Apex (if we're staying with Oracle). For reporting, I still use Reports Builder (and call those reports from Apex).
As of Forms still being used: most of our applications are written in Forms; much less number in ADF or Apex. Versions we (as a company) use are 10g and 12c.
Worldwide? Reading forum discussions, I've seen that people in India use Forms very frequently, and they still use client-server 6i version.
So, although there are rumors (that last at least 2 decades) that Oracle is going to abandon Forms, that didn't happen. Will it? I don't know. In my opinion, Forms is a very good tool whose main drawback is that applications developed in it look oldfashioned & ugly (more or less). Users prefer Apex-like applications nowadays.
Finally, note that this is a primarily opinion-based answer (because the question is such) so ... maybe the community will close it for further discussion. Personally, I hate seeing anything closed (here or on any other forum I visit) & hope that you'll get some more opinions.

What is a good approach for migrating from LINQ to SQL to DocumentDB?

First, a little background to our situation. Several years ago I started an ASP.NET MVC project using LINQ to SQL as the DAL. Being the only developer on the project at the time, I chose to use it because it was pretty well supported in the community and I needed to focus more on the application logic and UI design so I could get it to market. That strategy worked out quite well for us.
It wasn't long, though, until I needed to write some multi-threaded code in a Windows service against the same data store. LINQ to SQL encountered all sorts of problems with crossing threads. Still being the only developer at the time and needing to get this service up quickly, I resorted to duplicating just enough of the DAL and models using POCOs and Enterprise Library. Though not ideal architecture with duplicate models and DAL functionality, it worked well enough and got me through.
That was five years ago. We've been successful with our project to the point where that very success is now a liability not with LINQ or Enterprise Library, but with SQL itself. Now, before anyone suggests that we give our SQL database an overhaul with indexes and all of that, we have done exactly that. We added a DBA on contract and he solved the problem for us. Performance was restored and things were okay. The problem, though is that it requires (in our opinion) too frequent maintenance for our business model and requirements.
Thankfully, Microsoft has stepped up their game with Azure services. Of specific interest to us (we have two developers now), is DocumentDB. In SQL we have several large, flat, busy tables that give some areas of our application severe performance problems when we start to approach the need for DB maintenance. We simply don't have the resources to devote to ongoing maintenance. We've decided to move our application either in part or entirely to DocumentDB. A few proof of concept demos internally tell us that this is a good move for the type of application we have.
If you've read this far, thank you, and here is my question. What would be a good way to migrate the LINQ to SQL classes and generated logic to a DAL backed by DocumentDB? Thankfully, I had the foresight early on to use an IRepository approach such that the application itself won't be impacted, hopefully at all. I'm mostly concerned with all of the "magic" CRUD stuff that the LINQ to SQL design surface coded for me. My other developer and I certainly understand how to write our own DAL code, but we need a quick and consistent approach that takes into account the behavior that the application is coded to expect from having been backed by LINQ to SQL.
My instinct is to basically unwind all of the generated code that LINQ to SQL did for me five years ago and divorce it from the LINQ to SQL designer, add in our own DAL via DI and go from there. My other developer is more advanced than I am on that part of things, so I have a pretty decent amount of confidence that we can get it done. Just hoping somebody out there can help us avoid pitfalls so we can get this done efficiently.
As David Makogon points out in a comment, this question really has no "correct" answer as it is very broad and opinion-based. I'm getting a broad range of suggestions, but nothing I would consider a definitive answer.

SQL Server Analysis Services

I have a pending project that may or may not be a good candidate for leveraging SQL Server Analysis Services. The project is based around business metric calculations.
Does anyone have some good recommended reading for a crash course in SQL Server Analysis Services that'll let me catch up to speed on what the capabilities and uses are to help me decide if it is worth digging in to further?
Thanks
I've been reading Delivering Business Intelligence with Microsoft SQL Server 2008 by Brian Larson and think this is the best book for a beginner on the subject. He is a good writer and has an easy style. His focus is on the overview and allowing you to understand SSAS basics. I'm not sure a seasoned pro would get much out of it, but for me it was perfect. I've also got the Wrox Professional book, which has far more detail but is a less enjoyable read.
here is the answer for a similar question on stackoverflow, and has some useful links for a SSAS beginner. However some links for msdev.com are not working as given in th eanser but rest are good.

How to establish database connectivity in Silverlight application?

I am developing a RIA using Silverlight its completely Database Driven Application but I dont know how to establish Database connectivity?
I am using MsSQL database and C#
I found the answer to my question upto a good extent... so sharing with you all
Check this link it contains a great set of documentation on using ADO.Net data services in Silverlight.
I found one more good article so editing my answer.... but its the luck if this works for you if not then author of the article donot respond :( quite sad...
Here is the best link i found hurry!!! It solves the problem.. Lots of thanks to kencox the sample is with SQL2008 but i tried it with sql2005 and it worked so You can also try it with MySQL hope it works for you too...
Well, it depends what database you are using, if you're using mysql, you can have a look here:
http://www.mysql.com/products/connector/
And get the .NET client.
If you're making an application hosted on the Internet, you don't want the RIA directly accessing the database. Firewalls make this unfeasible, and it could expose you to dangerous attacks. Typically, you'll have a web service as an intermediary. If you really need a more direct connectivity to data, you may want to consider ADO.NET Data Services.

Database for Open Source Project [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Which database would you use for an Open Source Project?
I am looking for something that has little or no setup required by the end-user.
Update: Database size will be relatively small (less than 100,000 records). Application will be written in C#.
If you're looking for embedded database (I guess you do if you ask for something easy for end-user), then SQLite is the most widely deployed SQL database in the world.
Depends on what language you're using, you might need appropriate wrapper for SQLite library.
Update: For .NET, the best wrapper for SQLite is System.Data.SQLite.dll from phxsoftware.
SQLite is nice if you want an SQL-queryable DB:
http://www.sqlite.org/
It doesn't require a server; you just need to include and use the appropriate API libraries in your project. Your database gets stored as a single file on disk.
It depends so very much on how much heavy-lifting that database has to do, but I think it's worth looking into SQLite. It's an amazing little piece of C/C++ code, it's distributed under a public domain license (meaning you can literally do anything you want with it, including resell it).
If you do not need atomic transactions, or very intense type-checking, then there probably isn't a better database. You add the library to your application and it works like a SQL database. Most programming languages have bindings for it. It would be hard for you to describe a case where some other database would be needed.
If it's a web app with PHP then MySQL ... it's installed pretty much everywhere that has PHP installed (which is almost every host).
If it's not... consult the other answers :)
Go with SQLite. It does not need any kind of installation by the end user. It just works.
What about an object database like db4o.net?
Have you looked at SQL Server Express It isn't open source but it is free. I'm a big fan of SQLite but if your in the .net world and want to use a microsoft stack it may be a better choice. It provides some things like T-SQL and a strong type system that SQLite doesn't provide. It does have performance and db size limits not found in the full SQL Server versions but this probably doesn't matter for your application.
I'd second the comments regarding SQLite. It's great for what it is - and for most small, no install DBs, it works very well.
There are a couple of other options, though.
Firebird is one option. It has a pretty impressive feature list, and also includes a .net provider (albeit in beta still).
Another option, though not open source, is VistaDB. It's a 100% managed option, unlike SQLite and Firebird (and most other DBs out there), and has a lot of advantages because of that. It's fairly consistent with MS SQL syntax, supports stored procedures, and many other nice features. They have an "Express Edition" that's free, and can be used in open source projects.
It would depend on what you mean by "end-user"
As others have said SQLite is a great choice if you are looking for something embeddable or for a desktop use.
If you are thinking of some sort of web app, I'd say either MySQL or PostgreSQL as these will provide better performance and be able to handle a large data set more naturally.
If it's windows only Sql Server Compact Edition is a good choice for small apps. It is freely redistributable.

Resources