Related
I have a database that I need to distribute to users (it's a directory of contact details) probably on CDs.
Users have varying platforms (OS and device wise - I'm willing to target desktops hence CDs).
I was thinking of some kind of deployable webapp that would provide a nice interface and a sqlite database. Does some kind of db interface exist with a highly customisable ui? Or does someone have a better way of doing this?
How big is the database? One simplistic option would be to generate a "contacts" webpage and burn this to the CD. Users can then search this from their browser or perhaps you could do it for them using javascript.
If you really need a DB then you're looking at an embedded database of some sort, however, since you've suggested sqlite I suspect you know this already and are looking at user interface options.
You have not specified a technology, so I'll just list several frameworks designed to develop database backed webapps:
Grails (Groovy/Java)
Rails (Ruby)
Django (Python)
All the above operate in a development mode that uses an embedded database (H2 or Sqlite). Your only challenge will be to ensure their runtime environments are properly configured, or shipped on the CD as well.
In conclusion, I pretty certain this has been done before. Have you also considered just shipping an installer for your webapp, rather than worry about the complexities of getting something to run from CD? For example you might wish to support more than one platform: Linux, Windows, Mac, etc.
Update
Someone has thought of doing this:
http://www.benjysbrain.com/misc/cdsite/
At my work, my co-workers are considering using hyperfile as a database server for a windev project. I don't even know that kind of database, it's from PCSOFT, the company that develops windev.
Since windev can also work with microsoft sql server, I'm looking for advice on that kind of database (performance, stability, etc) from people who already used it.
Regards!
It depends on the size of your project. Actually, Windev works well with HyperFileSQL. It has been designed for it ! By using another DBMS, you cut yourself some feature such as direct-reading/modifying/deleting in your tables.
Your performances will decrease significantly as soon as you have a nice amount of records in a table (> 100'000). Your database management will become a nightmare since you can't execute several SQL requests at the same time. In example, i'm using another tool developped by a french guy to manage my databases and execute some updates.
Despite of this, it's stable and provides an easy way to interact with Windev's fields.
In my opinion, Hyperfile SQL should be used with small applications with a small amount of features and datas.
Adding upon what Samuël Tremblay already wrote, I would say that after 2+ years of using Windev with HFSQL (old name is HyperFile SQL), here are my conclusions (I have used Windev versions 20 and 22):
PROS:
replication of a database to another server is rather easy to setup. You can choose to replicate a whole database or a selection of tables. But DBMS like PostgreSQL are actually offering advanced replication setups (https://www.2ndquadrant.com/en/resources/pglogical/).
easy export to a Microsoft Excel file of a query/table
create and change the schema/structure of your database through a graphical user interface (GUI)
CONS:
When you use the database server provided by Windev (i.e. HFSQL), you must use Windev (that is imposed upon you). You cannot interact with your database with another language/framework other than Windev, you are forced to use Windev to query a HFSQL database. If you use instead a DBMS like PostgreSQL, mySQL/MariaDB, etc. you can (and will be able) to query the database with some other language : C++, Java, JavaScript, etc.
Say that you wanted now to open your data to customers through a web app, you will actually need to use their other software Webdev from their software suite (and buy it actually).
Or say, some day, you want to develop a simple app for smartphone with Qt or else. Well, if your database runs on HFSQL, then you will not be able to query your database unless you use Windev (actually Windev Mobile that you also need to purchase).
UNIQUE constraints are not working with the presence of NULL (two rows containing NULL would be considered to violate the UNIQUE constraint).
(almost) every time you update your "analyse/analysis" (basically the database schema), you will also need to update your binary executable. You will need to recompile your software and distribute it again to the users. For example, say you modify a table by adding a column, or modifying the type of a column, then you need to recompile. The executable that the users have will not run, it will say that the version of the "analysis" (schema) on the database is not the same as the one in the executable, and will stop. BAM !
the HyperFile SQL (HFSQL) server is not so stable, it will crash (often) when executing slightly advanced queries with not so many rows...
You cannot create scripts to query the HFSQL database : you must create a binary executable (a new project) with Windev. Say you want to quickly modify something --> you need to recompile (and have a Windev IDE with you).
Say you are on the go, on some trip, and you forgot to bring your computer with the Windev Dongle key (a license cryptographic USB key : it you don't have it, you cannot run Windev), and you need to do some work on the database. PCSoft provides a software called HFSQL Control Center (a GUI software) that can interact with the database, but unfortunately it cannot be downloaded from the internet. You actually obtain it when you buy Windev, and you are allowed to distribute it to whom you want, but it cannot be downloaded from PCSOFT website.
Whereas if your database engine is another one, say PostgreSQL or MariaDB, you can simply download PGAdmin or the equivalent, and boom you can interact with your data.
It seems to me that HFSQL is not a real/genuine DBMS, let me explain myself : the constraints you can set in the analysis (UNIQUE for example), are not always respected. For example, after adding a UNIQUE constraint in the schema (analysis) and compiling the program, I have seen that if I would insert some data in a table from the executable, it would detect the violation of the UNIQUE constraint when it should happen. However if I would insert the same set of data through the HFSQL Control Center, the constraint would not be enforced and the duplicates would be insterted.
There would be more to say ...
Bottom line: From my own experience, I would strongly encourage anybody, who wants to develop a reliable and dependable software that "must" be developed with Windev (and that needs data persistence), not to use their database HFSQL. You would be much better off using a RDBMS such as PostgreSQL or MariaDB. We are actually going to port our databases from HFSQL to PostgreSQL this Summer.
You should carefully consider what sql functions you will use. For example deg2rad, rad2deg, ... not working correctly.
Also if you want to use it on a mobile device (Windev Mobile for iOS or Android) you should use SQLLite. Because HyperFile uses a lot of memory and it will be a problem on mobile.
If you want a free database, use PostgreSQL, the Windev connector for PostgreSQL is free to download and install on your windev as a replacement for HFSQL, it will be way more powerful while using the usual hFunctions like you would with HFSQL, plus you will find a ton of docs on the web to do powerful stuff.
HFSQL is in fact the same as an old ISAM DBASE database so it requires re-indexations and things like that of those older DB systems era.
PostgreSQL is like having a free Oracle DB with all the powerful features and reliability, we dropped HFSQL for this and performance has increased tenfold plus all the other benefits while keeping our code pretty much the same, every day feels like we discover freebies and gifts from ProsgreSQL since our migration :)
Free VS Free... You gotta go with power and sheer size of web documentation and poeple available to help .
In WinDev Mobile 18 and up, you can use Hyperfile on the device. And it is recommended from me, because it is faster and SQLLite restrict blob-size to 1MB!!
#Spek memory usage of HyperFile on the phone? Can you give me any values? I think if you want to make a full feature APP you cannot ignore the benefits of HyperFile...
FYI: New in Windev version 19: Hyperfile SQL is ACID.
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.
This is something I would like to see while doing my day today programming works, But I've never seen such application yet. You input is highly appreciated.
Lets say we have an application that needs MSSQL server as DBMS. And suppose you just need to install it and do something. (i.e You are not going to deply it in production servers etc.)
In such a case it might be an overhead, of installing MSSQL first. I am suggesing something like a software bridge that can use another DBMS to store data. In other words the application "sees" an MSSQL instance but underneath that it might be Access. The bridge sholud do some sort of conversion.
Another example : You have MSSQL but a certain application needs Oracle. You have to purchase Oracle then. But with a something like a bridge, You can put information into your MSSQL DBMS. The bridge listens to port 1521 like Oracle so application "Thinks" there is an oracle installation.
Is it an idea that cannot be implemented?
Are there any such applications?
If so what are they?
Thanks... :)
Adding a Clarification : The application might be from a third party. You don't have any knowledge on internal architecture of that. you just know it uses a certain DBMS. I am trying to use a different DBMS other than the third party software needs.
Application usually don't depend on a specific database server, OR they depend on it for a reason.
If an application asks for oracle, or sql server, or whatever, it's because it relies on the implementation details of this specific vendor to run its SQL, its stored procedures, etc. There's no way you could emulate that with an access database, for example...
If your application just needs to run some very simple SQL (ie basic insert/select statements), it probably uses a standard driver (odbc, ado, etc.), and those drivers can accommodate every major sql database engines. In my experience, "simple applications" don't ask for a specific database vendor.
This is the problem that ODBC was supposed to solve :-) .
But in response to your questions:
Is it an idea that cannot be implemented?
It can be implemented.
It would be tedious and thankless work, and you would have a very limited audiance. In my opinion it's not worth doing.
Are there any such applications?
None that I know of.
If so what are they?
None that I know of.
......
Bringing in Chandrasekar's note in the comments section:
Have a look in a super user's perspective... He has a nice application but he can't use it without some DBMS. But still he is not a programmer to do something. So they need such a product
I agree it has applications, but it has a very limited audiance :) .
What you're proposing is something like the firefox plugin 'ietab', Only you won't have ie installed... so instead of embedding ie, you would need to entirely re-implement ie using firefox's rendering window.
Just my opinion : that's too much effort... It's simpler to just install a second database.
If this application uses ADO to connect to SQL Server and you can modify the connection string, then it's quite easy to use a different database: change the connection string! However, the other database must be able to support all features of SQL Server. Besides, the software was never tested on another database so the application might Crash & Burn.
If you can't change the connection string, or the application doesn't use ADO, things are more complicated and very close to impossible.
I've worked in the past on a project that needed to be reasonable database-independent. The database had to support stored procedures but there weren't any other restrictions. By default, we tried to support both SQL Server and Oracle. (We also supported Interbase but never advertised this.) While we did manage to keep it mostly database-independent, we did have to work around quite a few minor issues. Especially joins in our queries had some nasty problems which we just solved by adding more logic to stored procedures.
"This is the problem that ODBC was supposed to solve :-) ."
And it is the very same problem that SQL was intended to solve too.
It seems to me that the reason why this problem exists is that the world seemingly fails to agree sufficiently on what the data manipulation language/interface ought to look like.
I suspect that if this were solvable, it would already have been done.
The closest I've heard is EnterpriseDB where they have built a layer on top of Postgres so it looks more like Oracle.
But remember these databases have features covered by patents and copyright so there's a limit on how closely a competitor product can imitate the real thing.
It would probably be easier to imitate 'down' than up. For example, MS-Access wouldn't be able to imitate much of the functionality for Oracle or SQL Server, whereas there's a much better chance of SQL Server imitating a simpler DB like Access.
Applications usually DO depend on a specific database server. Every database implements things slightly differently - even MSSQL and Sybase, which have a common ancestor.
Any bridge, however well it attempts to abstract the differences, would leave some exposed. These would be likely to create subtle bugs in the application, which might appear initially to work, but then fail, or worse, corrupt data.
Moreover, the application vendor would not support you in such a case - they'd simply say they don't support that use case, and you should remove the bridge and install a proper instance of whatever database it was intended for.
In short, I don't think it's worth the risk of the application malfunctioning subtly, and being left without support, even if the application isn't especially important. If you dislike the underlying database the application uses, choose a different application.
I would like to build and deploy a database application for Windows based systems, but need to live within the following constraints:
Cannot run as a server (i.e., have open ports);
Must be able to share database files with other instances of the program (running on other machines);
Must not require a DBA for maintenance;
No additional cost for run-time license.
In addition, the following are nice to have "features":
Zero-install (e.g., no registry entries, no need to put files in \Windows\..., etc.);
"Reasonable" performance (yes, that's vague);
"Reasonable" file size limitations (at least 1GB per table/file--just in case).
I've seen this question
Embedded Database for .net that can run off a network
but it doesn't quite answer it for me.
I have seen the VistaDB site, but while it looks promising, I have no personal experience with it.
I have also looked at SQLite, and while it seems good enough for Goggle, I (again) have no personal experience with it.
I would love to use a Java based solution because it's cross-platform (even though my main target is Windows, I'd like to be flexible) and WebStart is a really nice way to distribute software, but the most commonly used DBs (Derby and hsqldb) won't support shared access.
I know that I'm not the only one who's trying/tried to do this, so I'm hoping I could get some advice.
I'd go with SQLite. There are SQLite bindings for everything, and it's very widely used as a embedded database for a large number of applications.
I use SQLite at work and one thing that you should keep in mind is that its file based and uses a file lock for managing concurrent connections. It is not a great solution when you have multiple users trying to use the database at the same time. SQLite is however a great database for one user application, its fast, has a small foot print and has a thriving community built around it.
If you've got VStudio sitting around, how about SQL Server 3.5 Compact edition? MSSQL running in-proc.
http://www.microsoft.com/sql/editions/compact/downloads.mspx