In Asp.net can we use Ms access as back end, can we do manipulate the data if we use back end as ms access.
Sure, but I certainly wouldn't call MS Access directly from your asp.net code behinds.
Take a look at something like the MVC or MVP models as a place to start. Call services which call the data layer instead of coupling your front end to any particular data store.
You can use MS Access as your back end, yes.
I certainly wouldn't suggest it though. There are many other compact choices (such as SQL Server Compact Edition or SQLite) that I would consider more stable and robust.
Yes you can use MSAccess.
You will find more about Retrieving Data Using the AccessDataSource here. Also have look at this article about ASP.NET Data Access Overview there you will find about AccessDataSource Class
Hope this helps
You can make use of Access for sure. In the past, with classic ASP, this combination was quite frequently used for small websites.
If you want to keep on using Membership, roles, ... then you can also do that with Access as there are already providers available for that. Take a look at this article on how to grab the providers and make use of it in your application: Using Access instead of SQL server for your ASP.NET Application Services.
Related
I have ASP.NET project and I want to know what is better to use.
ODBC connection and with Server Explorer (drag and drop make DataSet and modify it) or do some DBconnect class with connection to database, queries and use it for GridView?
When I use server explorer, I don't have good feeling because all logic is on aspx page and I do not separate from the application layer logic layer.
It will be a lagre application, databese(PostreSQL) have 18 tables and difficult constraints and application have to generate some documents etc. .
"Better" depends entirely on your situation. Is the purpose to get something done as quickly as possible for internal users at your company, or is this going to be a commercial site that will need to be highly extensible and needs to be as easy as possible to maintain? Will you need to integrate with other platforms possibly built using other languages at some point? The answers to all of these questions should affect your decision.
If you're looking to separate your project into distinct layers, then I would recommend an ORM such as NHibernate or Entity Framework (there are other commercially available ORM products out there, but these are the ones I'm familiar with and which you can easily get help with on this site).
Create a DataSource with LINQ to Entity. It let you the liberty of LINQ with the peace of mind of when you change something il will break your build so you will be able to debug more efficiently.
Well if you have total flexibility, I would recommend using C# ASP.NET 4 with MVC3 razor for the UI and application code. Use Entity Framework 4.1 code first for the data access layer.
This way you will always work with real objects that you create, and with List<realtype> instead of the total mess that exists with datasets.
What would be the pros and cons of taking a large (16000 LOC) existing Access 2007/Forms application and porting it to SQL Server 2005, while keeping the Access forms on the front end, versus porting the front end to a .NET technology, say ASP.NET 4.0 or MVC3? The backend is definitely getting ported to SQL Server, with large schema modifications, so this question is about whether to use the existing Access Forms front end or not. I don't take throwing away existing working code lightly! On the other hand, the schema will be changing a lot.
If you had a lot of experience with ASP.NET/Oracle but not with Access or SQL Server, how might this change your answer?
Thanks,
Mike
There is nothing wrong with Access as a front-end to an RDBMS whether SQL Server or another
Porting the front-end but leaving an Access back-end would seem a bit weird: why bother? Access is a good presentation tool but mediocre DBMS. Why keep the mediocre?
Also, only change one component at once no matter what you do: data, then front end. Don't do a big bang approach and change the lot
Actually, comparing going with web application (ASP.NET) and stand-alone (Access) is not truly "apples-to-apples" comparison. It highly depends on your requirements.
Sure, going with web application will require much more developer's efforts comparing to building forms/reports in Access. But, the pay-off will be felt in the mid to long term.
You should also consider scalability, deployment, and availability issues when deciding to go/stay with Access.
I am working in a school and we recently installed a new server running WinServer 2008R2. I want to be able to point people to a URL on our intranet and have them fill out a simple registration form and have this data written to a database. It would also be nice to have some data auto-populate (such as their name).
Is it overkill to set up a sharepoint server and try to do this with Access Webforms?
Could I use something like dotnetnuke and find a module that works? Or how about options for writing custom forms?
Personally, I would definately not go with sharepoint for such a simple task. Besides money issues sharepoint is difficult to properly set up. Even with custom ECT's within sharepoint administration is a nightmare.
I would personally create a simple asp.net web form with some standard fields and you could use SQL Server or mySQL to push this data into a database. As for default values, that depends on how you want to set the fields, you could use windows authentication and set their user name to their NT login.
Creating a web form to fill in and collect data is not too difficult.
Have a look at http://www.asp.net/get-started. It is something you will find a lot of tutorials for. You might like to consider MySQL or SQL Server Express for your database. A Sharepoint server would definitely be overkill, unless you have some large ideas about sharing documents.
Sharepoint is way too overkill for something like this. Same for DotNetNuke or any other platform. Just do a simple ASP.NET page with an Access back end. I doubt you'll need anything bigger like SQL Server Express, although that might be a good learning experience.
I have a asp.net application which is written in the traditional method [SqlConnection. SqlAdapter.. ..] in data access layer, I can see that every time we are making a connection and using adapters. Code is written in a very dirty manner. I have been given the task to re write the application in standard/best practice way.
i have all stored procedure already written, is there any way I can use a tool like which will help me in writing the business layer and data access layer?
I suggest you to go for codesmith. As you have all the Stored procedure already written you can either go for the LINQ to SQL feature.
For the DAL, you could use Entity Framework 4. The business logic could be wrapped up by hand.
Take a look at fluentAdo.net. You can use it with all your old stored procedures.
But if you really want to rewrite your app, I suggest you to use NHibernate or Entity Framework. They have pretty same set of fetures.
Where can I get custom libraries for ASP .Net? Specifically I am looking for ready made database access library that allow me to select, insert and update a database using transactions. I know how to do create but I am trying to use an existent library that does all that and handles exceptions and errors so exempt from the hustle of creating that from scratch and go into errors.
You can use Microsoft's free Enterprise Library for DataAccess, Logging, Caching, Security and Configuration. It's very commonly used.
Also you can use code generators like free .NET Tiers, but you will need CodeSmith if you want to use it.
I'd suggest looking at either using LINQtoSQL and the DBML designer to map your database tables onto objects in your system or a more full-featured ORM, like nHibernate.
You may want to look at something called Speedy.net. I have never used it, but it looks interesting. I have used other code that these people have written, and normally it's pretty good. For the small amount of money that it costs it might be worth trying out.