The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Something like MS Access

Does anyone know of a development platform similar to MS Access that offers:
1) Really quick development of database linked applications.
2) Great reporting ability - *with* user definable reports.
3) Web UI
4) Desktop UI
5) Royalty free distribution of applications.
6) Supports activex controls or similar.
7) Easy distribution of applications.
8) Works on windows.

I ask because access is a bit sucky for (2,3,6,7) with MDAC, IE and run time size hassles.
Kim
Wednesday, March 01, 2006
 
 
Does anyone know of a development platform similar to MS Access that offers:
1) Really quick development of database linked applications.
2) Great reporting ability - *with* user definable reports.
3) Web UI
4) Desktop UI
5) Royalty free distribution of applications.
6) Supports activex controls or similar.
7) Easy distribution of applications.
8) Works on windows.

Kim,

Does not your point number 2 and number 5 conflict.  To use the Access reporting features you need to buy an Access license rather than the run time which is the royalty free way of distribiting applications built on access?
David
Wednesday, March 01, 2006
 
 
David: "Does not your point number 2 and number 5 conflict."

Sure do. That's why I'm looking for something else that enables this.

I figure MS does not enable this so they can make more money, which is fair enough, but annoying to me.
Kim
Wednesday, March 01, 2006
 
 
There's FoxPro, also by Microsoft, and also FileMaker. But I don't know if they meet your criteria, you'll have to check them out yourself.
Chris Nahr Send private email
Thursday, March 02, 2006
 
 
I also second FileMaker Pro -- I'm not sure about ActiveX, but everything else works great.
Berislav Lopac Send private email
Thursday, March 02, 2006
 
 
I believe Visual FoxPro meets all your requirements, and MS is putting some new life into it (Sedna): <http://msdn.microsoft.com/vfoxpro/>
Former COBOL Programmer Send private email
Thursday, March 02, 2006
 
 
Delphi with a good third-party report component such as ReportBuilder will satisfy all your requirements.
Karl Perry Send private email
Thursday, March 02, 2006
 
 
Visual FoxPro looks awesome.  Under $1000 and no .NET requirements, built in database with it's own SQL engine so you don't have to setup SQL server or anything on the client machine.
anon
Thursday, March 02, 2006
 
 
Funny that in 1992 MS released Access 1.0 (http://www.microsoft.com/Office/previous/access/10years/history.asp), and acquired Fox Software (http://www.foxprohistory.org/foxprotimeline.htm). Since then FoxPro has languished on the vine while Access flourishes. Hmmm.....
Former COBOL Programmer Send private email
Thursday, March 02, 2006
 
 
I'll agree that Fox isn't one of Microsoft's star products but it isn't going away. When I was converting to Visual Fox the VB guys told me I really ought to ditch Fox and invest in the language of the future. Ten years later those VB people are having to relearn and rewrite everything but I'm still busy and productive with Fox. And it looks like the Sedna upgrade is giving us access to anything we need from dot Net too.
Geoff Franklin Send private email
Thursday, March 02, 2006
 
 
For a "development platform" and having a royalty free database engine, applitcation development with the ability to have a desktop and web ui you're going to have to seperate from looking for a single product to meet thoses needs. Best bet would be to pick a programming environment and a free database engine and run with that. Something like VS Express / MSSQL Server 2005 Express, or VB any version and just using Jet. Or there's whatever supported and SQLite.
TrippinOnIT Send private email
Thursday, March 02, 2006
 
 
Try and download Oracle XE and use the built in Application Express. (apex)  It has a lot of nice features (nice GUI).  You do everything over the web.  You could probably use Active X controls but probably don't need to.  If you want to distribute it the customer could install it as long as it meets some criteria. (see EULA, 4 gig custoemr data limit etc.)
Jim Send private email
Thursday, March 02, 2006
 
 
The C guys hated VB.  Fox was never on their radar scope.  Thus the travesty of VB.Net.
Cur Mudgeon
Thursday, March 02, 2006
 
 
Oh for God's sake.

Will you anti-VB .NET people ever find something else to do with your lives?
Kyralessa Send private email
Thursday, March 02, 2006
 
 
Geoff, I admit, I drank the MS kool-aid and choose Access/VB over FoxPro. Not that Access is a bad tool, but I wish I had learned FoxPro as well. From what I've seen of it, it's quite powerful...
Former COBOL Programmer
Thursday, March 02, 2006
 
 
Why did fox pro languish and access turn up everywhere?

I've never seen a fox pro program, yet lots of businesses have Access programs.

Was it just because it was part of office? Is Access easier to get started?

Is Fox Pro the betamax of desktop database solutions?
Kim
Thursday, March 02, 2006
 
 
Why did FoxPro languish?

Probably because Access was built primarily inside Microsoft, while Fox was an acquisition.

The two products are fundamentally different, too.  Fox was built around dBase, which uses separate disk files for each code unit & for each data table, index and memo file.  It didn't have a strong WYSIWYG report writer at least at first.  Its roots were in DOS.

Access, OTOH, is all one file (yes, I know you can split the DB's but fundamentally it's a monolithic file system), it was originally built for Windows, and it used Basic as its back-end - which was Bill's favorite language and formed the backbone of the programming extensibility of the Office suite of products.

From a Microsoft business perspective Access was and is a better fit with the Microsoft way of doing things than FoxPro.  That doesn't say that Access is better, it just fits into the Microsoft world better.
Karl Perry Send private email
Friday, March 03, 2006
 
 
I'll bet that you've seen a FoxPro application and didn't know it.  It's been used in alot of applications and very successfully.
FoxCoder Send private email
Friday, March 03, 2006
 
 
Does it still run the Channel Tunnel between England and France?
lc
Sunday, March 05, 2006
 
 
What happened to FoxPro?

We had this discussion a number of times.

Near the top of the list is that ms-access had better design choices in the early years.

Microsoft is a classic case of a company that comes out with architecture to solve a problem.

Ms-access was the result of some VERY forward thinking and advanced concepts.

MS came out with some technologies like DAO and JET. What was MOST important here was that the JET engine was a SEPARATE data engine from the product. This means that ms-access in effect had to communicate with this data engine. For most part, this thus forced developers to use sql. A Listbox, a combo box, reports, forms etc all used sql. Virtually everything was built around sql. You *had* to use sql to communicate with the data engine. While separation of the data layer from the programming layer was not new concept, or a huge deal, it meant that when client to server came out…the product was ready.

Ms-access was not the first product in the market place that had variable length records, and separated the data engine from the code..but it was the right decision at the right time.  Other products could do well in the marketplace without these features, but their future was doomed (FoxPro was such a product). MORE important, the programming TECHNIQUES those developers had been using in ms-access would work with sql server. That 2nd point about techniques is MORE important here!!

The philosophy of how developers would write code in access prepared them for when client to server computing came along. Ms-access did not have the concept of a record number. Modern database systems don’t have record numbers, but 15 years ago, on a PC based system, that was not the norm. (access is now 14, going on 15 years old).  If your code does NOT rely on record numbers, then in a  multi-user environment, you can delete a record…and not suffer any consequences as a result of a record deletion. It also means that you can not, and do not assume a particular order of data.

FoxPro lived on record numbers, and ALSO assumed ORDER of data. So, as a developer MUCH of the code you write in fox actually relied on sequential data. IF you write out 5 invoice detail records in fox…you know they will STAY in that order (and, so thus did your code). So,  your code then can read back 5 records. Really, this meant that physical order of data was exposed to the coding environment. In a multi-user environment, this makes no sense at all, since 5 records written to the file could be all from different users.

To be fair, sequential data processing was still quite in force 15 years ago. Well, FORTRAN for that matter was big on card order too! So, products of the day were built around this philosophy.

Modern database systems don’t keep order because it don’t make sense in a multi-user environment. It doesn’t make sense in client to server as you can’t “open” the file for sequential direct processing either. Sequential processing and DIRECT opening of a file was the order of the day back then.

Dbase, FoxPro etc where based on a sequential fixed length file. Much like punch cards. This means that all code written was based on a fixed length records. MUCH code in fox relied on this order. So, when you wrote code in FoxPro, you will essentially writing code for the data engine, and there was little separation between the code layer, and the database layer. And, record numbers were the order of the day (pun intended).

The design of ms-access was based on architecture that was VERY forward thinking on MS’s part. This is classic MS. I think the .net decisions made a few years ago will also bear this type of fruit in the future….10 years from now. Everyone will wake up..and realize that the decisions made now were good ones.

Those design decisions made 15 years ago when ms-access came out did not mean much back then. However, the design decisions made back then is exactly why the reason is we are still using ms-access today. It is for the most part not really changed a lot from 15 years ago. Ms-access developers have not had to re-learn, or throw out a zillion different technologies. It has been a long run…and MS is working on one of the larger new releases of ms-access as we speak now.

FoxPro was not only handicapped in terms of architecture, but when windows came out; the first versions were not really that great. Again, ms-access was windows from day one.

MS did purchase FoxPro, and by the mid 90’s had seriously re-engineered the product to remove those original handicaps. By then, it was to late…and ms-access had essence taken over the market.

So, MS did not dish FoxPro…but purchased a very successful product (at the height of its value by the way). They then spent the next 5 years re-working the product to the realities of client to server (or, at least a separation of code from the data engine).

Today, FoxPro is one of the best kept secrets as Microsoft, and I would certainly agree it is a better development tool then ms-access. (it was, and is full OO…before even .net was out).

However, who wanted to learn the dbase, or FoxPro  language? That is the other main problem with Fox.

The other really large decision was that when office 97 came out (about 10 years ago now), they choose VB for the programming language. When you learned ms-access, you used the same code and syntax as VB5 (and, when a2003 came out..then  vb6).  So, ms-access enjoyed a MORE compatible language. If you learned ms-access, you were learning VB (the syntax is identical to VB…except for the forms object model).  So, when you learned ms-access, you were learning sql, and you also were learning VB. Both valuable skills.

Ms-access won because it had a better overall design that was forward and future thinking.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Sunday, March 05, 2006
 
 
8 months ago I have retaken an application in Access after someone was developing it for 8 years. It has become quite robust application and now every little change in this application means hours of additional debugging. Yes the application might have been designed poorly, but an advanced development tool should allow (by it’s design) so many problems.
I have done several applications in FoxPro and back then I though FoxPro is a bad tool. Now I see Access is far worse. I can make Access crash totally several different ways, I found at least 4 error codes with description "Reserved error", to make programmatic calculations work with forms you have to put textboxes bound to respective fields on the form etc... I really don't understand how complex systems done in Access can work
Normally I develop in real languages (C,Java,C#) and have not similar problems. If you have bug in your code and find it, you will say to yourself 'oh, it is obvious why it doesn't work', but in Access I usually say to myself ‘Why doesn’t it work the logical way?’.
  I hate those people blaming computers, programming tools etc. of mistake instead of searching mistakes in their application, but now I am convinced that Access isn’t good development tool, at least for medium or bigger sized projects.
  Also notice Access forums content. Someone posts message like ‘I have done this and that error comes up’ or ‘... this doesn’t get saved’ and then some MVP tries to help him.
  Have you noticed similar forums for C++ or any C-derived language or environment (like .Net Framework)? Only questions for algorithms or obvious bugs like bad pointer operation etc. are present.
 Well, this is my opinion on Access.

The next thing is : “...(it was, and is full OO…before even .net was out)...” – FoxPro became OO tool in 95, the C++ begun in 83 and became used widely around 91.
Another thing: “full OO” means nothing. Only term “pure OO” is used, for example for Smalltalk, which was by the way developed in 73.

I will welcome active discussion about Access as a good development tool.
Michal Javornik Send private email
Monday, March 06, 2006
 
 
Access is an interesting tool, often the bane of the software community.

>Also notice Access forums content. Someone posts message like ‘I have done this and that error comes up’ or ‘... this doesn’t get saved’

I totally agree with the above. However, I don’t believe that these questions are due to problems with the product as much as the kind of user base you have.

I’ll state that I am somewhat looking from a access point of view here. I am a Microsoft MVP, and a access one at that!

I would also note that the public.access newsgroups answer about 30,000 questions per month. (yes…you read that correct – about the largest group as far as I know).  So, I believe the user install base is in excess of 100 million. (and, remember, access has been around for 14 years now).

The problem is ms-access has a two sided personality.

You have a VERY large user base that are NOT experienced developers, and for the most part are not trained software developers. Between wizards, and building forms etc, this user base is quite large. To be fair, 10+ years ago, this was for the most part where a  LARGE portion of pc developers came from.

So, the real reason why you get those weird questions is because the c++ newsgroups does not have a LARGE user base of non software developers.  Remember, ms-access has both a rich end user feature set and a large developer base also.

(two diverse groups, and the newsgroups is thus a match made in heaven for both!!)

Even more interesting is how many people don’t realize how difficult software development is..and ms-access tends to often make people realize this fact.

I would say that a FAIRLY large portion of my work is the result of people discovering they are in over their heads!! (about 40% of my  work comes from products started by people who can’t finish them…or want the product fixed up).

Now, On the other end of the spectrum are people like me who use the tool to build and deploy commercial grade applications. So, in my case, then I not going to use macros, and wizards. It also interesting to note that ms-access is the ONLY office product left with a macro language. (all others have long since dumped macros..and now use VBA. – of course the macro recorder in other parts of office does produce VBA…and most users could not care less).

In ms-access, both macros, and VBA can be still be used.

Now, the next question is a big one, and a fair one:

    Is ms-access a qukery development environment?

Well, as a developer who has deployed a lot of access software, I find the deployed software VERY reliable.

Many developers who find ms-access querky is because they are used to using MUCH MORE clean and simple environments to accomplish their task at hand.

Also, the programming language in ms-access is identical to that of VB6 (the only difference here is that the forms object model is different). And, while ms-access and VB6 share the same compiler, ms-access does not have a native compile option.

One of the problems when doing development in ms-access is learning the forms object model. In this case, you actually have something with a MUCH MORE steep learning curve then say VB6.

The comments about how clean other development platforms seem is fair, but of course then you don’t get to use the complex forms object either.

Here is a simple example of what I mean. Many (a lot) IDE’s have tools to create a form, and then you can open the form.

In ms-access, a form has two load events (in vb…you only have one!!).

So, in ms-access you have two events
    on-open event occurs first
then
    on-load event occurs

Quick question (one I use if I am hiring you).

What is the difference between the two events, and why/how do you use each?

If you don’t understand the difference between the two events, and when or why to use one over the other, then even experienced developers tend to just cobble over this issue. They just use either one willy nilly without thinking. Then, all of a sudden they ask why can't a field be modified in the on-open event? Then they find the tool hard to use. This type of issue comes up in MANY places in ms-access. You MUST take the time to learn the object model, and how the events work. If you don’t, then you will find the tool difficult, and it will SEEM inconsistent.

If anyone wants the answer to the question of on-open vs on-load events…..just ask..and I'll post here…

For example, you mention the product is difficult to work with. Do you ALWAYS deploy a mde to your users? Funny how I often meet developers with years and years of experience who ALWAYS distributed a executable with whatever IDE they use, and then come to ms-access and stop what they done for 15+ years.

For example, is your application split? I explain why you split here…but as a developer, this article should not be needed…

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm


Also, the issue of having to place controls on a form to use the underlying data source is not correct. If you change the forms record source in code, then any reference via me. (me dot) can actually break. If you use me! (me bang), then you do NOT have to have the control placed on the form to use the underlying data). Again, this is simply one of those issues that you must learn. It is quite a simple lesson, and once you learn how this works, then all of a sudden your forms code does not break…

I going to stop here…perhaps we start a new thread. The real question is how complex, and how large of an application should build in access?

And, perhaps the question for many should be at what point to NOT use ms-access to develop a software project?

Of course, the same debate can be said of VB6.

I believe for most small business, ms-access is a ideal development tool to produce business software. It works well for me….better then anything else I used….

I am open to being changed on this issue...but it will take some good discussion!!

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Monday, March 06, 2006
 
 
You are sadly mistaken if you think that FoxPro relys on record numbers in any way, shape or form.  Yes, you could have seen poorly designed applications that did but that was not the rule.  Access forward thinking?  Hardly.  In fact, until the improvements in the data engine that came from, wait for it, FoxPro, Access was a horrible choice as data corruption was an everday occurance, especially in multi-user/network environments. 

Can good applications be coded with Access?  Sure just as poor ones can be done with FoxPro or insert any other developement tool name here.
FoxCoder Send private email
Wednesday, March 08, 2006
 
 
This is in regards to FoxPro Ver. 9
1) Really quick development of database linked applications.
By code or IDE, FoxPro developed apps use base class controls that are data centric. FoxPro uses a native DBF style tables and DBC style database, including free tables which if need be, can be embedded into the application to support meda data requirements. It can connect to most other databases through ODBC, ADO etc. Supports remote views (updatable or not). SQl pass thru, SQL in ver 9.0 is close to ANSI compliant.

2) Great reporting ability - *with* user definable reports.
Good reporting tools and is OOP. Actually developed an app reporting to html, no need for reporting tools.

3) Web UI
Need third party tools, and they are out there.

4) Desktop UI
Great part of Fox, full set of controls, can use 3rd party controls,.OCX’s and the best part, can develop custom controls (visual and non-visual).

5) Royalty free distribution of applications.
100%

6) Supports activex controls or similar.
The market place seems sparse, but most controls developed for VB seem to work fine in Fox. I have compiled ocx’s in VB and used them in my FOX apps. Also, you can build many different types of controls in FOX eliminating some dependency on 3rd parties.

7) Easy distribution of applications.
Distribution can be done by the use of an installation program. I have done the following ( some people would argue this is insanity but…) literally copy the runtime files, my app EXE to the application root folder and it runs great. If there are no other 3rd party controls, support libraries etc. to register, you’re good to go. Email me if anyone thinks this is nuts: this has worked from Ver. 5 thru 9.

8) Works on windows
Yep.
Final note: I have used FoxPro for 10 years along with other fine products. FoxPro has provided little disappointment and is long on performance. It will be supported through 2014 by MS. I agree with the one poster, FoxPro has never relied on static record position. “Record number” is a design property from the beginning. It has outlived any useful application as it applies to nTier development. In earlier versions, good applications had little reliance on the record number. That’s why SEEK and LOCATE were there from the start.
Ron Olson Send private email
Tuesday, March 21, 2006
 
 
> You are sadly mistaken if you think that FoxPro relys on record numbers in any way, shape or form.

For the record…it USED TO in the late DOS days, and early windows days.  I CLEARY stated that this was NOT the case in later years. Please re-read my post.

In the early years, the whole use of the Fox language DID use record numbers. It was NOT just a issue of poor coding practices, it was an issue of architecture. 

The WHOLE PRODUCT FUNCTIONED AROUND RECORD NUMBERS.

Further, those record numbers were EXPOSED!!!

From the foxpro 2.0 help file
<quote>

LOCATE FOR <expL1>
    [<scope>] [WHILE <expL2>]
    [NOOPTIMIZE]

 ───────────────────────────────────
 Locates a database record.
 ───────────────────────────────────

 The LOCATE command sequentially searches the currently
 selected database for the first record that matches <expL1>.
 The database need not be indexed.  The functionally similar
 FIND and SEEK commands do require an indexed file, but are
 generally faster than the LOCATE command.

 If the LOCATE command finds a matching record, RECNO() will
 return the record number of the matched record, FOUND() will
 return a value of true (.T.) and EOF() will return a value of
 false (.F.).  The record number is also displayed unless TALK
 is SET OFF.

</quote>

I hate to burst your bubble, the RECNO() function above is returns a RECORD number that is based on a ABSOLUTE position in the file . This is NOT a identity field, and this is NOT a primary key filed. This is also NOT the same as the “absolute” position in a ADO recordset , or sql “cursor” (or fox cursor for that matter!!!).

The above is a record number. If you understand what this means,  you will realize that RECNO() is actually a byte offset from the start of the file on hard disk, and multiplied by the FIXED record size to resolve to the location of the record in the file.

As I said, this was a old style punched card type system.

This whole system relied on FIXED record sizes.

At that time, virtually EVERY major function in Foxpro used the recno() to resolve to a record. This was a disaster that would haunt Fox for years to come….

In addition, the SEEK command also returned  a record number in FoxPro.

Of course a developer would NEVER use those recno() for any external meaning. (you could not anyway, since a pack command would CHANGE the recno() values anyway!!!.).

However, that is NOT my point here!!! I am not suggesting the problem here was that record numbers were a problem when given meaning by poor developers.  It needs pointing out that identity fields in sql server also can’t be given external meaning either.

That was not the issue here, or my point. The issue was that code relied on the recno(). That meant that the number was a fixed position in the file. If you wrote out 5 records to a file, then those 5 records would be RETUNED IN THE SAME ORDER. Thus, as a general approach to code in fox, record order was ASSUMED. 

So was record order assumed in FORTRAN when you read punched cards, or data from a magnetic tape.

ORDER OF DATA was assumed by these systems. You can try and argue that this could be avoided, but the architecture simply encouraged this use. It also meant that multi-user design was not given consideration in the design of the data engine.

How can you have a client to server architecture that needs the server to return a fixed record number position when virtually ALL MODERN systems don’t even have that feature today!!!. How can you request the 30th reocrd from a JET (or oracle) database?...you can not!!

Recno() was not a primary key, but actual record position relative to the START of the file!!!

In modern databases, 5 people might add the next 5 records, and the concept of recno(), and data order make no sense at all (the next 5 reocords have ZERO meaning here). And, a  few of those records in between might be deleted!!!  The recno() idea is of NO use. If you moved to the next RECNO(), you could be moving on to a record that was just added by someone else! There was NOTHING in the system to prevent this from happening. With ms-access, you cannot code this by accient.

The WHOLE DATA engine in Fox requested data BY NUMBER POSITION ORDER IN THE FILE!!!

The JET database engine in ms-access, or the oracle database, or sql server NEVER EXPOSED the internal record numbers used as did Foxpro. There is no such ability to “move” to the next record number at all. Sure you can request records into a cusor..and move through those…but you CAN NOT traverse the actuall physical data file in order like you can in old fox.

Further, since these newer systems had variable length records, and thus a absolute record position pointer based on size x reocrd# could NOT be used anyway!!

The architecture of the product  was wrong, and was not correct for client to server, or multi user environments.

The fact that most of fox code DID NOT use sql to restive data shows this point also. Sql was EVENTUALLY added, and integrated into the product.

The issue at point is why fox stumbled at one point in its history.

Of course today Fox has no such issues, and these features with effort from MS where abstracted to work with client to server, but it was not pretty.

So, as a general rule, the language and architecture DID rely HEAVILY on record numbers, and as I explained, it was a bad mark against fox. It hurt the product bad, and made transition to client to server databases VERY difficult.

It was only after YEARS of effort by MS is now the product a FIRST rate product for use with sql server. However, ms-access was that way from day one…..

That was long long time ago in a far away galaxy.

Today, Fox does not suffer from this problem…but it certainly did at one time…..

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Friday, March 24, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz