Front end

  • I'm just in the process of moving over from access to SQL and I need some advice on what is the best front end to use.

    I've heard about access data projects and linking tables to a MS Access DB.

    The db will be used by up to 25 uses and they will be using forms to input data into the tables.

    So I'm looking for some advice and assistance to help me with this.

  • You could Visual Basic or .net applications to build applications to wor with SQl server.

    However, Visual baisc is the most simplest and commonly used application builder with Sql server.

    --Kishore

  • Be aware that using ACCESS will require each user to have it (ACCESS) installed on their machine with a licence for each.

    If you're going to get someone in to do this for you, I'd go down the VB.NET (or C#.NET) / ASP.NET route - development times are much shorter, and by making it web/intranet based, you'll remove the need for any sort of installation (and updates) on the client PCs.

    Hope this helps,

    Tim

    PS I hate ACCESS...... !

  • We have been using an access front end and SQL server backend for several years.  The program evolved from an Access front and backend application.  The performance across a WAN is terrible.  We moved to Citrix to keep the thing moving.  We are migrating to a .net frontend.  In the mean time you can use the Access database splitter to reconnect the Access frontend to the SQL backend.  Be prepared for occasional corruption in the Access appication.  Distribute only mde's.  Try not to go this way

  • I believe that doing an Access query against a SQL Server database will result in all of the data being copied to the Access machine so it can do the query.  If you are doing joins on very large tables, this can result in huge amounts network traffic.

  • I am not a DBA nor an Access developer.  The last few years I have been developing in the .NET environment.  However, I have worked with Access from time to time. 

    I would be very wary of Access.  My experience is that it takes absolutely no knowledge of development to create an application, but quite a bit of knowledge to develop a good application.  Access has a deceivingly steep learning curve and does take a solid understanding of software development to create something that works well and can be maintained.  My (admittedly limited) experience is that few Access applications are written by knowledgeable people. 

    In addition, Access is an older technology.  It has many levels of compilation and, for reasons that I do not understand, leaves old code behind during compilation.  This leads to corruption of the application.  It is prone to crashing during development.  I have had instances where the most recently compiled code did not execute.  Instead code from a previous compilation was executing.  There is an undocumented feature (a switch) that fixed the problem, but such things should not occur. 

    I would agree with those who suggest the .NET environment.  This is going to be the focus of Microsoft’s attention in the future, not Access.  It is an excellent development environment and should continue to improve. 

  • I want to defend Access 2003. It is an excellent product, and can connect to SQL Server by making a Project file, rather than linking. A Project file uses built in, native drivers and is very quick. You cannot have any data in the Project file, but rather if you create a table, it creates it in SQL Server. All queries are SQL Server views or stored procedures.

    I agree that poorly written programs will result in poor performance, but that can be said about any program. A bad SQL command will be bad in Access, VB.NET or ASP.NET, it dosn't matter.

    .NET is the way to go, but if you don't have the resources to throw at .NET development, and you have experiance in Access and the necessary licenses, then by all means, try a 2003 project file.


    Shalom!,

    Michael Lee

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply