I'm building online examination system and i want to use accdb for database. My question is will accdb allow multiple students to read the test from the database?
not clear what you mean by on-line? Do you mean you are building a web based applcation of some sort?
Access does allow multiple users to work against the database at the same time. This typically means that you split the database into a front end (application part) and the back end - a accDB with just the tables.
And you can use the access database (engine) to drive data for a web site. However, you don't and can't use VBA or the access forms for this purpose.
Since you ONLY useing the tables and not anything else releated to Access when you build such a on-line system? Then in most cases, little if any reason exists to use the access data engine, since any of the business code and UI will be built with different tools then Access. And every web site hosting these days offers MySQL, or SQL server or some other database.
These other database systems are far more approcilate and work better with multi-user operations.
So, keep in mind when you use the term "Access", you are talking about two parts:
The data base engine - (ACE, or previous called JET). This data engine (like most database engines) does not provide any UI, reporting or anything, but is just a system to hold the tables and data. You then write the web based "on-line" software with asp.net, or whatever technology stack that you are familier with.
The 2nd part of access is the so called IDE (integrated development enviroment). That part of access lets you write code, build forms, and build reports. However, that part is not web based, and thus using the term "on-line" does not really apply here. Access IDE when used is strictly 100% desktop only.
In fact, often, if you need a multi-user applcation, we often will build + use MS-Access to build that windows desktop software, but will still choose to use a server based database system like SQL server or mySQL.
So, access alone does not really give rise to a "on-line" system, and that would require that you adopt a set of web based development tools.
Related
This question covers a number of areas, so may ultimately have to broken up into constituent parts. However, I don't want to do this, at least until I have some general idea of what direction I should be taking!
I want to create an online booking system under the .Net Framework. The GUI would have two separate vital areas. 1. would be the typical form GUI for setting up a user account. 2. would be a Calendar (much in the same vein as Google Calendar - if not actually Google Calendar) which would show users available times that users can book, and hopefully allow them to actually book by simply clicking on an available time as displayed on the calendar.
The available times that would be displayed on the calendar would depend on two things: the type of user the user is (would be specified in the signup form) and also (obviously) whether or not other users have already taken available slots.
One big question I have is whether it is possible to use Microsoft Access (any version) for this task. My preference is due to familiarity, and the fact that most other technologies being used in this development are Microsoft based. I know it is possible to migrate Access DBs with SQL Server - but would this include the vital front end (i.e. the form)?
Finally, The strategy for approaching the calendar aspect of the front-end is doing my head in a little! While it is certainly possible to integrate SQL Server and Google (docs/calendar) I feel that attempting to shoehorn Google Calendar into such a complex relational database would be ultimately infeasible - but I am struggling to think of an alternative without having to do my own development (which, in this case, I am seriously attempting to avoid!)
Any guidance on the above would be greatly appreciated!
My $.02: as #Luxspes said, Sql Server has no "forms" or "reports", but the SQL Server engine is better suited to web-based applications than Access's "Jet" engine. You could, however, develop your application in Access and then "upsize" your database, which tells Access "hey, those forms and reports are great, but now I want you to put the back-end database into SQL Server Express (free) and keep the front-end in Access." You can then publish your forms and reports to the web using Access's own tools, getting them "for free" while getting the better database engine on the back.
Be aware that doing this is not generally acceptable in the commercial world. An Access application looks like an Access application and most of the world will recognize it, and most don't like it: it will seem like you're cutting corners unless you can make the forms look really, really good. For in-house use it's fine because it has a fast turn-around time so the ROI is great. If you're making a commercial site, I'd take a look at the Microsoft MVC 3 framework: it will take a while to get your noodle around it, but once you're up to speed you can develop sites pretty quickly and robustly. If "robustly" is a word.
Is it possible to use Microsoft Access (any version) for this task, the task being using Access as the database for a online booking system under the .Net Framework: Yes. (But I would prefer to use MSSQL Express Edition)
I know it is possible to migrate Access DBs with SQL Server - but would this include the vital front end (i.e. the form)?: No, SQL Server has not concept of "forms". If you already have them in Access you would have to re-create them in, for example, ASP.NET. If you are looking for the easiest fastest way to do it, I would recommend you LightSwitch ( http://www.microsoft.com/visualstudio/en-us/lightswitch )
Finally, The strategy for approaching the calendar aspect of the front-end is doing my head in a little!: If you do no want to code it, you can find it in Google, just write ".NET Schedule control"
Our company is upgrading all work computers soon and no longer supporting MS Access. Unfortunately, a lot of important database is stored in a plethora of Access databases with many differing styles of interfaces. Storing it all on a database server is out of the question. What is a good portable (non-server) database system that I can use?
The one I'm leaning toward is SQLite, but I'd also like to be able to write interfaces to query the data. If I use SQLite, what is a good way to write a query interface that will work on a lot of Windows machines natively?
EDIT: Data migration will not be a problem. I'm more worried about interface migration. What is a good way to write a query interface for one of these portable database systems?
EDIT2: It seems that there's some confusion as to what I mean by "query interface". I don't need a complete query system. I'm simply looking to create a simple frontend through which I can search the Database by table and by fields.
Judging by the title of your question, you are concerned about what database (i.e. data container) should be used in place of Microsoft Access. However, viewing your question and the ensuing answers and comments, your greater concern is actually what to use to design the Application/user interface, what you are referring to as the "query interface".
Here's a couple things you need to realize:
1) SELECT queries allow you to extract data from a database. However, the data has to get into the database somehow. At no point have you specified whether or not your so-called "query interface" is also used for data entry. If it is in fact used for data entry, as I suspect it is, then you should concern yourself with how your going to design your "application", not your "query interface". Data entry often requires a certain amount of guidance and logic that is defined outside of the database. This logic includes (but is not limited to) things like validation rules, input masks, parent child relationships that are enforced by the GUI design. This is essentially an application, not merely a "query interface". Applications are usually designed to make data entry easier than having the user enter data directly into the tables. But even here you must realize that ultimately a user can't even enter data directly into a table without some type of application GUI, whether that GUI is something you've designed or not.
2) Microsoft Access is a Rapid Application Development (RAD) tool that allows you to quickly and easily design and save queries, forms, and reports. It appears to me that you're real question is, What RAD tool other than Microsoft Access can I use to develop queries and forms for viewing and entering data in small desktop databases? And what database would you recommend we use together with the RAD tool you're recommending?
Assuming I've properly defined your actual question, allow me to give my own viewpoint on this question. First, as has already been pointed out in another answer, as long as the clients are running MS Windows, you don't really need to move away from using Access/Jet/ACC as your database (data container, the part that holds the tables). As long as MDAC is installed an Access database should be "machine readable".
It seems to me the more important question here is what RAD tool should you use in place of Microsoft Access? After you answer this question perhaps it will help you answer the first question, of what database should be used. In answer to this question, let's be honest. While Microsoft Access has it's shortcomings, you probably won't find any other RAD tool that allows you to so easily create Forms for data entry. FileMaker Pro is one of the only competing products that I know of.
Yes, you could use Visual Studio .Net to create .exe runtimes. These runtimes can include forms for viewing and entering data as well as reports. I think you'll find that the learning curve is pretty major, especially if you are not yet familiar with ADO.Net which is very different from DAO or ADO Classic. If you want to give your users ways to create their own queries/filters or reports you'll have to design this functionality into your GUI since Visual Studio doesn't give you the easy wizards and design tools you'll find in Microsoft Access. While Visual Studio is far more powerful than MS Access, you need to realize that the development time for even the simplest of applications is probably going to be much higher, especially when you are first learning.
Are there any other RAD tools you could possibly use? I know little if anything about the different design tools listed here but this might be a good place for you to start: http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools#Desktop_Rapid_Application_Development_Tools
SQLite is a great option and will extend your reach to many platforms beyond Windows (iOS, OSX, Android, etc.). I recommend this. If you want to keep using Microsoft products, SQL Server Express or Compact Edition is another possibility.
Another solution, depending on what you are doing with these databases, would be Microsoft SQL Server Compact Edition which does not require an installer.
No matter what database you choose, you are going to be faced with migrating your queries to a different dialect of the SQL language (the actual syntax of your queries). They all have their quirks and features (and missing features). That is just the nature of the beast. It should be noted that you can still access a MS Access database in code without requiring the installation of MS Access.
It appears that the nature of the question has changed dramatically since it was originally posted. The question has apparently morphed into one about finding an user interface development environment that has similar features to Access. This is obviously an entirely different question than finding a replacement for Access (or specifically Jet for those anal retentives in the audience) as a database engine.
There are many alternatives and it depends greatly on whether you wish to continue with a Windows application or whether you wish to move to a browser based interface. Given various comments, it sounds like you may still want a Windows based solution. A couple of solutions you might investigate:
.NET Windows Forms - The .NET environment is incredibly powerful and provides for very rapid development. IMO, as rapid as Access if you know what you are doing and far more powerful. However, with those additional capabilities comes additional complexity. No question that jumping into Windows Forms from pure Access development will be daunting but rewarding.
Another solution, which I admit to not having tested myself, but looks promising is Kexi + SQLite which is geared as an open source replacement for Access.
If you considered changing gears and switching to a browser based approach, there are again many choices. PHP, ASP.NET (MVC and not), Ruby and so on. As with Windows Forms, switching to browser based development from Access development will be a daunting change but also rewarding.
Of course, if the PHB are eliminating Access as a cost cutting move, you could split the existing Access databases to Front-end/backend applications, migrate the backends to SQL Server Express edition (free) and have the users use the MS Access run-time (also free) You, the developer, are the only one who actually needs a paid-for full version of Access.
This response comes long after the question was posted--but Google still turns it up near the top of results for 'replace ms access'
You should include MySQL and PostgreSQL on your list of the potential replacements. MySQL supports AUTO_INCREMENT columns, so it might be a better replacement for the Microsoft databases. Also, Microsoft SQL Server Express might be not a bad option. I migrated from using MS Access databases to using MS SQL Server Express in my apps when I was using Microsoft technologies about 10-12 years ago.
Is it possible to use Access to create web pages? Let's say I have 20 pages that have the same layout but different content (ie- different address, different phone, etc...). I want the webpages to retrieve the information from the database rather than me having to hardcode each one.
Would it be possible to use Access to create a database that stores the info, then creates the page rather than having to hardcode it?
Thanks in advance
New for Access 2010 is the ability to build web sites. If you look at the following video, note how at the half way point, I switch to running the Access application 100% in a web browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
There several things to keep in mind when building web forms with Access 2010. The forms cannot have VBA, but must use macro code. This macro code is converted into JavaScript and does run inside of the browser. The resulting forms are standard .net XAML (zammel) forms. Server side code is possbile with writing data macros.
The Access reports you publish to the web are rendered` using SQL server reporting services. To use Access web services you need SharePoint or wait until office 365 comes out which will also support publishing of Access web applications. (so, just like there will be web based versons of Excel and word, there also a web based version of Access).
Since the resulting forms and reports are based on .net technology, then the resulting application scale VERY well horizontally (large number of users). The resulting applications do not require activeX or Silverlight (I tested them and they run fine on my iPad for example). Last but not least, there is no covert utility for existing VBA forms to web forms, you have to create new forms in Access that are designated as to be web forms. The new web based applications can have a mix of VBA forms, and web forms in them now.
MS Access is a database that can power your web application. You need to write a web application in ASP.NET (ASP, PHP, Java, Python etc) that connects to your database, retrieves and displays data.
If you are not a programmer check PHPRunner that can build full PHP code for all your tables in minutes.
For building a website, you can use Access in one of two ways:
as an application builder with A2010, as described by Albert Kallal. This is entirely dependent on Sharepoint (the expensive Enterprise version, though it can also be done with hosted Sharepoint). and requires that you limit your Access app to those things that are supported in web objects.
as a data store only (i.e., using Jet/ACE instead of Access), driving an application built in PHP or ASP.NET or whatever. I would not recommend this as Jet/ACE is not well-suited to use with a web server, except for read-only sites, or sites with very, very few users.
The dependency on Sharepoint is likely to make that an unacceptable solution, while the limitations of the Jet/ACE database engine make its use as data store only not really a good choice.
So, basically, I think you should choose a different database back end (MySQL, SQL Server, PostgreSQL) and build your application with PHP or ASP/ASP.NET or whatever is available.
In other words, there's still no magic bullet with converting an Access app to run on the web.
However, if the real problem is making the app available to many people in different locations, you might drop the web requirement and simply host it on Windows Terminal Server.
I've never heard of Access handling web requests. I guess the bigger question is, what would be gained from an approach like this? Access is a database, let it do the job of a database. It would be considerably better design and easier to support to just use it as a database backing a web site, which itself could then be written in any number of languages/technologies.
A simple .NET website with an MS Access back-end would most likely be the best way to go here.
Another possibility is, if the web pages seldom change, then use Access to create the HTML pages as text files. Then upload those files to your web server.
You would create the page in memory using VBA string handling along with vbCrLfs to separate the lines. Use the print # statement to create the lines in the file.
This technique would be suitable for pages that change say weekly or monthly or similar.
What are the strategies you employ to let multiple people work on an access database?
Is it possible to host it online and have its features still functional without having to develop a custom frontend?
MS Access as a software has a few nice features that don't require any programming to configure:
Drop down lists - choose one
Multi Checkbox lists - choose multiple
Is it possible to get all of these features available even when hosted online? I'm basically thinking of an alternate way to quickly get people to work with data using GUI features like the above without going the webapp<>MySQL way.
You have some good comments here. Keep in mind that things have changed quite a bit for access 2010.
Access 2010 allows you to build web applications. The development process is very much the same as it’s been for years, but you can’t use VBA in forms for these web applications (you use a new macro language). This new feature set allows you to publish applications you build to a website. Here is an video of an application of mine running in access 2010, and at the halfway point in the video I switch to running the access application 100% in a web browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
The above is for access 2010…due out this year. The above will require you to be running SharePoint services, or use an hosting service that supports "access web" services.
For previous versions of access, for all intents and purposes, it’s not a web based system at all. Now when you say multiple users, you have to clarify what kind of users and where they plan to be. If your users are on a local office network, then MS access can be used as a multi user system right out of a box with no additional coding and programming required. It is recommended however that you split your application into a front end part that’s deployed on each user’s computer. This Concept as outlined in the following article of mine.
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
Now, perhaps the users are going to be on notebooks and in different locations all over the country? In this type of case you are attempting to connect over a wide area network, or have users connect to the application over the Internet. This is a different problem. In this type of scenario, a good solution is to use something like SQL server for the backend, and you continue to deploy the Access front ends to each user’s computer. This application tends to be about the most cost affordable also. And using sql server + ms-access means you get to continue developing in Access for the most part like you always done. Another way to accomplish wide area use without resorting to sql server is to use something called terminal services. I outline these possibilities in the following article:
http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html
As mentioned, a few others here posted links to some of the new SharePoint features that you can consider using, but they not out untill later this year.
Multi-user Access apps are pretty easy to do for small workgroup user populations in the 15-25 ranger or smaller. Above that, a developer should consider upsizing to a server back end, with the trade-off being greater administrative overhead for the server vs. having to program the app more carefully if you retain the Jet/ACE back end.
As to online access, you this isn't possible over HTTP, but if you have a Windows Terminal Server available, you can host your app there and give users access to that. This is actually an extremely easy and efficient and inexpensive way to support remote users of an app, though the larger the user population, the more problematic it becomes. But by the time an Access app has a user population that would strain a Windows Terminal Server setup, you're no longer going to be using a Jet/ACE back end.
And with a server back end, you could give access to a SQL Server on a VPN over the Internet, and if you write your Access app really efficiently, even over a standard broadband connection, your users could still work productively.
Then there's the future of Access: in Access 2010, a great deal of work has been done to integrate with a host of new features in Sharepoint 2010. If you create your A2010 app using the new type of Access web forms and reports, your app can be uploaded to a Sharepoint server running the new Access Services, and it can then be used running in a web browser (not limited to IE and not dependent on any plugins or web controls, as was the case in the past with the completely worthless Access Data Access Pages). The data store can either be a SQL Server, or you could keep it Jet/ACE for users not accessing it via the web browser, and have the data stored in Sharepoint for the online users. Also, you can have an app integrated with Sharepoint running locally in Access that uses Sharepoint when connected to the Internet, and still be able to work offline when disconnected. When connected again, you synch your local changes with the Sharepoint server, resolve any differences and continue working.
The features are really quite remarkable, and according to what I've heard and seen, if the Access app is built entirely of web forms and reports, it will look and function identically when run in Access and when run in the web browser via Sharepoint. And if you need to have client-side features that you don't expose to the users running the app in the browser, you can still use traditional Access objects!
The Access development team's blog has a number of posts on what's coming in A2010, and there's a good video posted there demonstrating how A2010 integrates with Sharepoint 2010's new Access Services.
This constitutes a quantum leap in Access's web capabilities, which were previously almost non-existent, and I'm quite excited about this. I was formerly quite wary of the changes being made to Access that seemed entirely to make it a servant of Sharepoint, but now I can see that the benefit to Access users and Access developers will be huge.
One way i've heard of, is to import the access database into a SQL Server database.
(Almost any version will do.).
Then link to the SQL Server database with Access and let users use it as they did before.
Look at this link: http://office.microsoft.com/en-us/access/HA010345991033.aspx
If you want an online solution i'd recommend going with a normal web application architecture. (Talking to a proper database.).
I have never needed to support it myself, but from what I heard so far, performance dramatically breaks down as soon as you need to support multiple users writing simultaneously. I think this is because Access uses simple file locking to implement isolation, and this just is not the right technique for a concurrent database system.
Hosted on-line? Do you mean on the network? Technically it will work on a network but there is a reason MS-Access in not in Visual Studio - it is not considered a development platform - it is a desktop application. When MS-Access first hit the scene many people built applications using it. The multiuser functionality just is not there. Upto four or five users is ok. But I would not go for more.
I'm hoping you can help.
I'm looking for a zero config multi-user datbase that my winforms application can easily upload to a webserver folder (together with 1 or 2 classic asp pages) and am looking for some suggestions/recommendations.
The idea is that the database will be used to collect feedback entered by people filling in the asp pages. The pages will write to the database using javascript.
The database will subsequently be downloaded again for processing once the responses are in.
In Summary:
It will mostly run in MS Windows environments.
I have a modest budget for this and do not mind paying for such a database.
No runtime licensing costs.
Should be xcopy - Once uploaded to a website folder it should be operational.
It should not have a dotnet CLR dependency.
It should support a resonable level of concurrent access. Average respondent count would be around 20-30 but one never knows.
Should be a reasonable size so that uploads/downloads to and from the site will be reasonably fast.
Would appreciate your suggestions/comments
Many thanks
Abz
To clarify - this is a desktop commercial application for feedback management in a vertical market. It uses SQL Server as the backing store.
The application currently provides feedback management from email and paper feedback. I now want to add web feedback capability. Getting users to to make their SQL servers accessible to a website is not at option at this time as I am want to make getting up and running as painless as possible.
I intend to release a web based implementation of the software in the near future but for now am looking at the above as a pragmatic way to provide web based feedback collection.
SQLite comes to mind. It meets all of your stated requirements, is open source, and has a liberal license (public domain).
http://sqlite.org/
I would use 'normal' database (say MySql, Postgresql, Firebird, etc.) on server. Instead of copying files to server your winforms application would create custom tables (or even custom databases). After collecting data you could just get it back to your application using plain old SQL.
why reinvent the wheel ? If you want to collect feedback and stuffs from users of your app and if they are connected to internet, it might be a better idea - and in the long term cheaper - to use a service like wufoo. We recently switched from homegrown setup to wufoo and are very pleased. Check it out.
Otherwise you might want to take a look at sqlite orfirebird. Both of them are very robust, and have ADO.NET providers. Firebird scales from a single user to full blown client server system and has no .NET dependency.
If you really don't want a DB/SQL Solution, you could try simple text files and ftp/xcopy files down and parse them into the back-office server as needed. ASP/VBScript or ASP.NET can create the files to store the basic feedback comments. Need to consider security of course!