Re: Access vs SQL

Hello All,

Thank You for your responses! All of you have given me quite a bit to think
about!

Richard, I understand completely. A bit of background: Even though I am
developing a software package, I would not, by any stretch of the
imagination, consider myself a software developer. I'm an Engineering
Consultant for the Mobile Communications Industry. For the past 10 years,
I've been writing PERL apps (when necessary) to automate repetitive tasks
and make my life easier. These apps were for my use only. Over the years, I
have had several clients ask me to provide these small apps to them. So, I
moved from writing plain code, to writing an app with a user-friendly
interface. Now, my clients want more. And they're willing to pay for it
(above and beyond what they pay for my engineering services). Fortunately, I
knew enough to write a scope of work (basically for myself), just as I would
do for a typical engineering project. So, I do understand 'creeping scope'.

Regarding the ability to 'Plug and Play' a variety of DB engines, I have
considered this as well. At the beginning of this project, I was using C1
Express components (no data adapters, no datasets, just Express Tables and
an Express connection (OLEDB)). While this was extremely easy to implement,
I realized that there was no upgrade path (upgrade = rewrite). Now, still
using C1 components, I know (think) I can upsize to MSDE or SQL Server with
only minor code changes.

Gerald, I agree. Rather than trying to decide which DB engine is better,
it's safe to say that all are good, if used in the environment they were
designed for. Right now, wihtout thinking about growth, I could deploy with
Access (1-2 users performing updates, additional 3-4 users viewing data,
approximately 1-1.5GB size). But, this, based on what I have read, and your
comments, is near the upper limit of what Access was designed for.

JL, though it may not seem so, I am in a similar situation regarding IT
support. Even though all of the mobile operators have extensive IT
departments, the engineering and IT departments are always fighting. So, I
need my app to be self-maintainable.

After posting this, I'm going to install SQL2KDesktop (MSDE) and try to get
a feel for what it will take to do a migration (I already have SQL Server
running on another machine). I like Richard's idea of allowing the client to
decide which DB engine to use. Hopefully my coding and forward-thinking was
robust enough to allow this with only some minor tweaks. However, if I get
lost in a sea of errors, I think my backup will be to use MSDE.

Again, thanks for your insights!!

Regards,
Lee



"lgbjr" <lgbjr@xxxxxxxxxxxxx> wrote in message
news:exGmoIPPFHA.2144@xxxxxxxxxxxxxxxxxxxxxxx
> Hello All,
>
> I've been developing a VB.NET app that requires the use of a DB. Up to
> now, I've been using Access. It's a bit slow, but everything works. I'm at
> a point now where I need to decide if I should stay with Access or move
> the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a
> move. My list is a bit lopsided, as I have very little experience with SQL
> and quite a bit with Access.
>
> PROS for moving to SQL:
> Increased Performance?
> Increased Reliability?
> Lifecycle of Access?
> Future Access Version compatibility issues?
>
> CONS for moving to SQL:
> My limited knowledge of SQL
> Clients not required to have an SQL server
>
> I've added a few items to the PROS list, but with ?s, as I don't really
> know.
>
> If there are a few Access advocates and SQL advocates out there that could
> give me some viewpoints, I'd be more comfortable making a decision based
> on the facts, rather than my limited knowledge.
>
> TIA
> Lee
>
>
>


.

Relevant Pages

  • Re: Abfrage inkl. WHERE vereinfachen?
    ... >> in SQL Anweisungen vornimmst. ... > angenommen, Du hast auf 20 Clients eine Anwendung laufen, welche die ... Schreiben würde ich die Anweisung in Prozeduren unter Deinen Voraussetzungen ... Erlands Artikel kann Dir da erste Anregungen geben, ...
    (microsoft.public.de.sqlserver)
  • Re: Like I said...
    ... In the end, SQL and DB is the only place where everyone understands everyone, in a clear, unambiguous way, right from the start. ... DB updates are performed on a "single ... The cases where we encountered them had PC clients running the app via Application Mode, so that was not a bother. ... Usually the only customers where auto-update is still allowed are the small ones -- where there aren't enough clients to make autoupdates really useful:p -- those with large IT droids services have it forbidden, ...
    (borland.public.delphi.non-technical)
  • Re: Connecting FM to SQL Database (Pervasive) via ODBC and Frontbase Plug-in
    ... Without downloading and installing FrontBase SQL, ... SELECT * FROM clients; ... I currently have 2 tables in the FMdb related by the patientID field: ...
    (comp.databases.filemaker)
  • Re: Access vs SQL
    ... from Access, tweaked my app a bit, and viola, everything works. ... MSDE 2000 adds a bit of complexity, but I have to say, compared to ... > (above and beyond what they pay for my engineering services). ... > Now, still using C1 components, I know I can upsize to MSDE or SQL ...
    (microsoft.public.dotnet.languages.vb)
  • Re: OOP - a question about database access
    ... Object Pascal) +SQL which is a most improved version of VB. ... never a problem in my Delphi apps. ... pretty much the same as you have it in an object model driven app. ... But coding in Java provides sub-optimal performance ...
    (comp.object)
Loading