Companies that are running customized applications may find a migration to Linux too costly or complex notes Pete Morgan, a VisualBasic/Access developer. Morgan offers a few solutions to help overcome the challenge. Without compatibility, Morgan says, a significant number of businesses may not see the benefits in moving to Linux desktops.
The first release candidate for gambas 1.0 has just been released. Could that be the tool the author of the article is looking for?
http://gambas.sourceforge.net/
Forgive me if i’m wrong, but when Mono supports VB.NET won’t this solve the problem?
some VB developers still deal with vb6 and even lower versions so Mono and dotGNU would only solve problems for those who code in VB.NET for .NET 1.1
>Forgive me if i’m wrong, but when Mono supports VB.NET won’t this solve the problem?
Not for some years.
1. Mono is not complete.
2. Developers can’t expect a random picked linux installation
to support mono.
3. There are no development environment, the large part of
potentonal developers will not accept vim/emac/unix as
their development environment.
Standard disclaimer: this is my personal opinion/post, and is not any kind of company line. I post here because I like to get varied viewpoints on systems, and appreciate candid, but considerate, feedback.
Actually, all (99.9%) Access developers’ code is written in VBA (which is a variant of traditional VB designed for use inside Office). Access doesn’t run .NET code, so the short answer is no, mono won’t help.
It is also worth mentioning, though the author didn’t, that Access provides a few facilities that aren’t present (AFAIK, please correct me if I’m wrong) in Linux today:
1 – Rich Query: You can build a single Access report which is the aggregation of data out of an Excel spreadsheet, a SQL server, a DB2 mainframe, and a Windows SharePoint Services list. You can do this without writing a single line of code; it is essentially a giant JOIN.
2 – Rich expression service: the expression service in Access has built in calculation functions like Excel, but can also natively call SQL queries, run VBA code, and wash your car (okay, not the car). It is sort of a jumping off point, and engine which parses the bits of the expression and hands them off to the various components which rely on them.
3 – Wizards, Wizards, Wizards: Access is chalked full of wizards (which are actually Access Forms running VBA) for automating tasks for users, e.g. Mailing Labels
4 – Superb printing support: the Access designer for reports is entirely designed with the concept of printing (as opposed to on-screen viewing) in mind. All controls/content in an Access report are positioned in inches on the design surface. While to you and I, the thought of killing a living organism just to see sales figures is ludicrous, many business people still require this facility.
Looking forward to responses,
-Zac.
Use
http://www.rekallrevealed.org/
or
http://www.knoda.org/
or
http://www.kexi-project.org/
Lev
While legacy applications already written in VB may never
be ported to Linux, the solution is simple: Multiplatform developpement for ANY new solution.
– wxWidgets/C++ or wxPython while are open source allow proprietary software to be built on top of them. wxPython can be a very good replacement for VB.
– Java. With 1.5 enhancements, finally, Java it is a serious programing language. And yes, NetBeans as stated by the author it is a very nice tool, I run it on Linux workstations and work very very fine. I use Eclipse too, but for client side NetBeans it is what I like best.
– Mono. While in infancy and there are some unclear legal issues it may be used where wx or java are not the option.
However, my oppinion is that we still have to wait until the water betwen Mono and MS gets clear, and we see a good portability betwen the MS.NET code to Mono.
—-
I think as of this moment, Java and wx/C++ are the best bets. We should educate business peoples so that they start to understand that any new investment in VB code may be nothing else but a liability in the future.
So you develop on a platform designed from the start to be Microsoft only, and you’re having trouble moving away from the vendor. Shocking! Porting the ugliness of a monster spaghetti Access/VBA application to something more reasonable is probably never going to happen. If those people are to ever use Linux they’ll have to use Wine/CrossoverOffice or move to a Terminal Server approach to run the “application” from a Windows server.
Thanks for the links! Would anyone who uses these products care to comment on how difficult it is to migrate solutions to them from Access or FileMaker?
There are solutions : Gambas is a brillant one, RealBasic is one another (cool but closed source). But this is not enough.
IMHO, developers wait for something around OpenOffice.org. OO.org is perfect for rich reports, but the Basic part is complex, undocumented and not easy to use. The good point is that OpenOffice.org could be a viable solution, even better than the VB.net solution : a lot of VB developers don’t like VB.net, as they’ll probably not like a Java + OpenOffice.org solution.
For example we needed to make an accounting system. We made it with OpenOffice.org Basic, and it was really a pain. But now it works, it uses databases and make complex documents (invoices, etc.), with some output to pdf (cool). The only problem we get is that each time we wanted some information, some people said “you should switch to python + OO.org or Java + OO.org”.
Now a lot of Unix guys will probably say that we are stupid to continue to use Basic… and that’s the real problem. Microsoft never said to VB developers that they are stupid And so VB guys stay on Windows.
But,I hope time will change this.
Sorry for the english (I’m french)
Use
http://www.rekallrevealed.org/
or
http://www.knoda.org/
or
With VB/Access, I can simply package up the VB program as an executable and it will install the necessary DLL files on a user’s system in order to access the .mdb Access file.
quote
While legacy applications already written in VB may never
be ported to Linux, the solution is simple: Multiplatform developpement for ANY new solution.
– wxWidgets/C++
– Java
– Mono
/quote
Typical answer… to use something different will not help people to switch existing applications from VB to Linux. We don’t ask you to switch to C++ or Java for the kernel development, because we respect your choice, even if we believe that C is not always optimal (I prefer Smalltalk, so please switch to Smalltalk).
I don’t think VB developers like to ear things like : forget existing applications, forget VB and switch to something 100% different. They just ask for a bit of comprehension, and perhaps more tools for OO.org or other applications that can be used instead of VB+Access or VB+Office.
The article don’t try to say “we need VB on Linux” but to say that some people made the choice of VB, and that tools to go from VB to another Basic are needed to make them switch to Linux.
You have to admit, unfortunately, that there is no replacement for Access and “Access Forms” for linux. This is irrelevant for most people but I can personally see how this would hold some folks up.
Sure there are alternatives, some very good ones, but nothing as simple to use.
I spent some time consulting at a local company that engineers GMOs (Genetically Modified Organisms) for the agricultural industry.
They have “developers” who do nothing but create and maintain applications using Access + Access Forms, which are entirely visual and require little or no coding to build entire data-driven applications.
They’re bloated, slow, buggy, and seriously lacking in features…but they can be built literally in minutes for something simple.
This same story can be applied to another local company, a very large microchip/memory manufacturer, who’s “developers” have spent years entrenching themselvs in MS Access and other Microsoft Technologies.
These companies, which are big and MASSIVE, respectively, may never seriously adopt Linux anywhere in their organizations simply because they’re knee-deep in MS technologies.
I agree… but,
I really think that OpenOffice.org is (almost) as powerfull. The only problem is a lack of tools, informations, examples, etc. But since we work with it, we contribute (just a little) to solve the problem. The main problem is that this is not easy to be (almost) alone on a platform. A RAD solution works better with many users
VB developers must know that OO.org is a viable alternative. Of course today this is not the easy way… but with 1000 OO.org Basic developers and a few months, the documentation, tools and examples will flow.
If it seems not possible to switch to OO.org, VB developers must know that it has the technical abilities to make complex applications. So switch today, you’ll not regret it (we don’t .
If it seems not possible to switch to OO.org, VB developers must know that it has the technical abilities to make complex applications. So switch today, you’ll not regret it (we don’t .
Are you telling me that any Access frontend I’ve written using VB6 can be re-written in OO.org with the same level of functionality? (Pay attention to that last part, that’s important.)
I worked for years with databases and Many MANY companies are relying on Fox (because it’s fast, becase it’s “old” and they know it, because, because, because…) Ask a the data offices in any marketing agency, they possibly use Foxpro. Because many Data repositories (some relying in huge DB/2, Adabas, Etc.) are often exported as plain txt files. I haven’t seen anything faster than Foxpro to handle those files (I’m talking about 3 Million ++ records per “table/file”.
A lot of people *could* be using a unix/mac/etc. workstation, if they had a chance to operate with those files and perform data normalization, joins, queries, etc. That’s their daily stuff. Telling them to perform a bulk insert into a MySQL is not an option…
There’s a huge market hidden there which Linux/Other cannot exploit due to the lack of known/easy to use software in that area.
my 0.2c
Martín
“The article don’t try to say “we need VB on Linux” but to say that some people made the choice of VB, and that tools to go from VB to another Basic are needed to make them switch to Linux.”
Maybe “we” – whoever “we” are in the Linux community – don’t necessarily NEED them to switch to Linux.
Maybe these companies who have locked themselves into MS technologies will find themselves at a competitive disadvantage (all other things being equal) over the next ten years and go out of business.
Gambas is an option for these people – except for one thing. It is NOT compatible with Visual Basic – “and never will be”, the author says. He claims it’s BETTER than VB.
So now what do the VB developers say? If his claim is true, do they sit there and say, “Well, we can’t port even though it’s better because it’s not the same?”
The same story is true of COBOL. Where are the Linux COBOL compilers? Where are the developers begging to port the literally billions of lines of COBOL code running most of the major corporations in this country?
Does it matter?
No.
Things will proceed as they always have. Linux and its development environments will continue to outpace closed source development and eventually become the standard.
You can either catch up or be left behind. That simple.
Why would a company want to switch from one of the most powerful and easy to use development environments(most people don’t really appreciate the power of Access) to something way more complex? In my opinion if this is something that someone would actually consider.The best soultion would be to run a Citrix cluster(RDP sucks) to run the access frontend. Then backend it with the database of your choosing like PostgreSQL( a better choice then MySQL).
>Are you telling me that any Access frontend I’ve written
>using VB6 can be re-written in OO.org with the same level of
>functionality? (Pay attention to that last part, that’s
>important.)
Yes I think so… You can use the internal database fonctionnalities. Forget “spreadsheet based” databases (Read Only). On the other hand we managed to use the Dbase module easily (no network, that’s the only problem). For network you can simply use a MySQL database but you can’t create it directly from OO.org. Any other Windows database can be accessed too.
Of course the interface between the software and the database is not very complete, but the roots are here, so everything that is not available can be made with Basic code. And OO.org Basic is very closed to VBA.
Anyway another guy who works with me could be more precise Is only problem with OO.org basic is the lack of an auto-completion feature (and so, he needs to switch everytime between the IDE and the documentation).
> Typical answer… to use something different will not
> help people to switch existing applications from VB to
> Linux.
This is what I meant. There is a lot of legacy code which is set to run on Windows. You are not going to change that and we may not be too concerned about that either.
Nobody in a company is nuts enough to say: Starting with tomorow 2:35 PM all Windows computers are to be thrown away.
However, after some time, the software is to be rewritten since maintaining it to meet new business requirements may be worst than redesign-it and rebuilt it from scratch.
This is the point I try to make. In this moment, we should use a multiplatform technology. Since we are stack for a while in company with legacy Windows computers (cause of existing VB code which is not yet old enough) we can not write Linux only software. But we can make it crossplatform (wx/C++) or platform independent (Java).
The new software is going to run on the same Windows computers untill all the old software is going to be rewritten (due to business requirements, and not due to some fundamentalist attitude: “Let kill Bill”). In that moment, you have the option to switch to Linux, since you were smart enough to write the new software multiplatform.
> We don’t ask you to switch to C++ or Java for the kernel > development, because we respect your choice,
Possibly, in future all new kernels are to be written in C++ when the GCC team solve the efficiency issue with throwing exceptions. Linux in that moment may be a legacy OS. It is called progress.
> I don’t think VB developers like to ear things like :
> forget existing applications, forget VB and switch to
> something 100% different
The existing applications are to be keept in maintenance mode until they are replaced due to business requirements.
VB programmers will have the option to learn just another programming language. I did or do programming in: Assembly, Basic, Fortran, Pascal, C, C++, Java, Python, PHP and in my spare time I take a look to C#. I can testify that it is not the end of the world to learn a
new language.
Another option is to watch closelly the evolution of Ximian VB.NET in Mono and make sure that any new code written is 100% compatible with it.
> They just ask for a bit of comprehension, and perhaps
> more tools for OO.org or other applications that can be
> used instead of VB+Access or VB+Office.
If someone, somewhere, sometime wants to do that will be perfect. What I said is that in case this won’t happen it is not the end of the world. You have the option to switch the language.
> The article don’t try to say “we need VB on Linux” but
> to say that some people made the choice of VB, and that
> tools to go from VB to another Basic are needed to make
> them switch to Linux.
Again, it may be possible. But what if it won’t happen ?
Are you to stay tied to one company and one OS only because you made a bad choice sometimes in past ?
Possibly, when you made that choice it was not bad at all.
As mater of fact VB it is a very efficient tool for
developping small applications for Windows only.
If this was your environment it definitelly was a good decision.
But world changed in meantime. You have to be flexible. Learning java it is not a big issue. And a lifespan of a programmer is long enough to see some small companies poping up, growing, becoming giants, fadding away and vanishing. It happen all the time. I used to love a company called Digital Research and programming Z80 ASM. Was fun. Do you remember them ?
Re: The Usual Complaints
Gambas is an option for these people – except for one thing. It is NOT compatible with Visual Basic – “and never will be”, the author says. He claims it’s BETTER than VB.
Just for the sake of argument, assuming it IS better than VB, that only takes care of one part of the equation – the other part is Access. Does Gambas have some sort of underlying database engine where I can package it on a CD and say to a user “Here, install this on your system” without having to worry about whether he has mySQL installed or not?
Maybe these companies who have locked themselves into MS technologies will find themselves at a competitive disadvantage (all other things being equal) over the next ten years and go out of business.
Alright, let’s go with this argument. Say I spend a lot of time and engergy porting my VB apps to Gambas (not sure how I’m going to get my users to switch from Windows or Linux, but that’s beside the point) and everyone is happy.
So, let’s say that a few years into the future, the Gambas project goes belly-up and I find myself needed to port my apps once again. Now, given the fact that Gambas is open source, does that mean that when I need to port my app again, the code is going to write itself? I fail to see how the fact that the IDE is open source is going to make my job of porting any easier in the future.
Even if Gambas is multi-platform (which I’m not sure if it is or not), who’s to say that it’s going to be on my platform of choice 10 years from now when I need to port it again. And if it’s not on that platform, it’s open source, so I guess it means that I get to port that as well, right?
Of course the interface between the software and the database is not very complete, but the roots are here, so everything that is not available can be made with Basic code. And OO.org Basic is very closed to VBA.
Yeah, see how this works? I always have some open source evangilist preaching that his solution is the right solution for my needs, but the moment you start to ask questions, you pretty soon find out that’s generally a half-assed solution. Ok, so it’s not complete as of now, so don’t waste my time. Come back and talk to me when it’s ready.
> Maybe “we” – whoever “we” are in the Linux community –
> don’t necessarily NEED them to switch to Linux.
True, WE need to find solutions, not you. False, WE need as much people as possible under Linux (and not only the “choosen one”).
> The same story is true of COBOL. Where are the Linux COBOL
> compilers?
There are some GGC frontends for Cobol
> Where are the developers begging to port the literally
> billions of lines of COBOL code running most of the major
> corporations in this country?
They don’t have to ask for solutions, since there are many solutions
> You can either catch up or be left behind. That simple.
I don’t care, I’m a C developper too… But I don’t agree because it’s not the way I see the Open Source world. For me it’s not a “catch up or die” thing.
Now you don’t care, and this is absolutely normal. Other people does, and this is normal too. Open Source is a choice but also something that should be for everyone.
Last point, in real life, nothing is simple.
>> They just ask for a bit of comprehension, and perhaps
>> more tools for OO.org or other applications that can be
>> used instead of VB+Access or VB+Office.
>If someone, somewhere, sometime wants to do that will be
>perfect. What I said is that in case this won’t happen it is
>not the end of the world. You have the option to switch the
>language.
Ah, this time I understand you
100% agree. I just tried to suggest a solution that works and that is (almost) simple. VB developer can switch to another langage, but they don’t have too.
This is a very important point, because many will not switch to a solution 100% different (because they dont need to, as VB works) but could switch to a ‘not so different’ solution (because it’s easy, and because they like OSS too).
Good point for OpenOffice.org, it works also on Windows. So this is a simple step…
>> Of course the interface between the software and the
>> database is not very complete, but the roots are here, so
>> everything that is not available can be made with Basic
>> code. And OO.org Basic is very closed to VBA.
> Yeah, see how this works? I always have some open source
> evangilist preaching that his solution is the right
> solution for my needs, but the moment you start to ask
> questions, you pretty soon find out that’s generally a
> half-assed solution.
> Ok, so it’s not complete as of now, so don’t waste my
> time.
> Come back and talk to me when it’s ready.
You’re not fair… It works perfectly… Database interface is not AS complete but it’s perfectly usable. On the other hand, you can make PDFs directly (usefull for reports), but only with third party modules on VB+Access. So yes, there are some little differences, but this is not an “half assed” solution. In fact you could develop a whole office suite with OO.org Basic since you can access to all the parts of the OO.org API. And OO.org is very complete
Problem today is the lack of examples and documentation, but that’s normal since there are only a few users…
Anyway, you don’t have to use it, and I don’t ask you to use it. But if you wan’t to switch to Linux (that’s the topic) this is a viable solution.
Now if you don’t want to switch on Linux or use some OSS software, why do you read this thread ? I think it’s the subject, no ?
Does Gambas have some sort of underlying database engine where I can package it on a CD and say to a user “Here, install this on your system” without having to worry about whether he has mySQL installed or not?
I am pretty sure OO.o and Kexi have drivers for SQLite databases: http://www.sqlite.org/
I might be wrong, but I guess that rewriting a working VB app would be prohibitevily expensive and nobody’s going to do that just to run Linux on workstation, it would be cheaper to maintain an existing infrastructure – hey, many companies still use NT4 and crappy W95/98 – because it just works and I don’t think they’re going to upgrade without a compelling reason, why spend money trying to fix something that ain’t broken?
I work for what I consider a small to medium size company. A move to Linux is all but impossible due to years of MS Access and VB4-6 custom applications. We once studied the cost of such a move and didn’t get far before we determined is would be financial suicide to move forward.
Any long term cost savings due to a switch to Linux would be totally eclipsed by costs associated with the required reprogramming of existing applications. Companies have to justify what they have invested in existing operating systems and applications. You can’t simply toss a 400k in software in the trash, just because the IT Dept. had a desire to be on Linux. While it might be a nice thought, it’s not the way companies due their accounting.
The belief switching to Linux is inexpensive, cost effective, or practical, in many cases is anything but the truth. Applications dictate operating systems, and there is absolutely no way around in many long established corps.
There are always people here on OSnews looking at a switch to Linux from a technical perspective. These same people have less than a clue of the costs involved in the corporate world. Nearly anything is possible; practical from an economic view is often another matter.
> A move to Linux is all but impossible due to years of MS Access and VB4-6 custom applications.
Right. Not now. But in 5 years ?
Chances are you have some applications which you are going to rewrite them now or next year, because they contain old code difficult to maintain in order to acomodate your new business requirements. Right ? And you are going to develop some new software you need it, but you never used before.
Well, the new applications have to be written multiplatform and not in VB. They will run just nice on your Windows computers you use to run your current applications.
In 2 or 3 years, another set of applications become obsolete. You are going to write them multiplatform too.
In 5 … 7 years, all your apps are multiplatform.
In this moment, just install them on a Linux desktop, and stop to pay to MS for renewal of Windows 200x license.
No extra cost, since the new applications had to be written
and the obsolete apps to be replaced. But you have now options:
– Linux
– Solaris
– Windows
– Mac OSX
– Some new cool stuff which just come on the market
At no extra charge.
This may be a little OT, but are there no *nix Jet ODBC drivers available? Assuming there were, couldn’t you simply hook up to an Access application located elsewhere (I believe Access itself has this capability in the form of a Client/Server application, whereby the actual DB is on a share somewhere…)?
Chances are you have some applications which you are going to rewrite them now or next year, because they contain old code difficult to maintain in order to acomodate your new business requirements. Right ? And you are going to develop some new software you need it, but you never used before.
Actually, I’m afraid this is not the case. People develop these custom ‘applcations’ on Access and then reuse them forever, if they can. They really don’t want to rewrite something just for the sake of keeping current with technology. Access databases are often very old and contain loads of buggy, hard to maintain code, but customers are not interested in replacing a working solution. Remember, these are not computer scientists; in many cases, they are 50 yr. old finance guys who just happen to need a very specific report, and end up making it work through many hours of trial and error (and copied/borrowed code).
Also, re:
>Are you telling me that any Access frontend I’ve written
>using VB6 can be re-written in OO.org with the same level of
>functionality? (Pay attention to that last part, that’s
>important.)
Yes I think so… You can use the internal database fonctionnalities. Forget “spreadsheet based” databases (Read Only). On the other hand we managed to use the Dbase module easily (no network, that’s the only problem). For network you can simply use a MySQL database but you can’t create it directly from OO.org. Any other Windows database can be accessed too.
Is this true? Can I create a single report which queries data from a MySQL table, JOINs on one of the fields in that table to my contact list in Outlook, then JOINs that into a table of issues I have assigned to people in SharePoint, without writing code?
What about having a report where every other data item has a different background color, can I do that?
One more: can I ‘snake’ the data? This is the case of mailing labels where the data goes down to the bottom of the page, then wraps back up to the top and down again, knowing that there are 3 columns per-page, and automatically calculating how many labels will fit on a page based on the label-paper type then paginating after that? Is it that paper-aware?
I’m not being factious with this line of questioning, I really want to know.
One thing to consider -VB.NET isn’t compatible with VB6.
All these companies are facing a migration problem somewhere down the road.
(why do you replace your winning star player with a rookie?)
Microsoft’s worst enemy is Microsoft.
“This is where you will go today.”
possible alternative: perl, DBI, MySQL, mysqlcc.
fast development – simple.
won’t work where you need a rich front-end.
Rich front-end possibility: PHP & MySQL/PostgreSQL.
all reports delivered up by on-the-fly intranet web pages.
You can manipulate just about any data source, including Access & Excel, with perl & DBI.
YMMV – to me perl & DBI is way easier.
I get lost somewhere between DAO, RDO, ADO, ADO.NET and ABC.
Don’t forget the big database, Google, isn’t run on VB6.
Actually, I’m afraid this is not the case. People develop these custom ‘applcations’ on Access and then reuse them forever, if they can. They really don’t want to rewrite something just for the sake of keeping current with technology. Access databases are often very old and contain loads of buggy, hard to maintain code, but customers are not interested in replacing a working solution. Remember, these are not computer scientists; in many cases, they are 50 yr. old finance guys who just happen to need a very specific report, and end up making it work through many hours of trial and error (and copied/borrowed code).
You missed his point.
He is not suggestion changing current solutions, but implementing new solutions to be cross platform.
Locking yourself to one vendor unless you can help it is BAD.
The ONLY way you would think it is good for everyone to be locked to a single vendor is if you were the employee of that single vendor. Vendor lock-ins = Very Very Very Bad.
Cross platform solutions should always be considered, if possible do not choose something that would look you to a single vender.
“One thing to consider -VB.NET isn’t compatible with VB6.”
That’s entirely incorrect. The 2 are bi-directionally compatible: VB6 ->> VB.Net via Interop and RCW’s, VB.Net ->> VB6 via RegAsm.exe. It’s quite simple and painless actually.
>Is this true? Can I create a single report which queries
>data from a MySQL table, JOINs on one of the fields in that
>table to my contact list in Outlook, then JOINs that into a
>table of issues I have assigned to people in SharePoint,
>without writing code?
Yes. There is no AutoPilot for this but it needs only a couple of lines of code. Of course everything that needs code can be made with an AutoPilot… but it needs to be written (and I’m sure it will, since OO.org AutoPilots are most of the time Basic Macros). Basically VB AutoPilots just insert the needed code. OO.org is ready for this but needs documentation, examples, automatisation, etc. All can be done with Basic, so in fact OO.org only needs… a community of Basic users (no community = no tools, no tools = no community)
Hum SharePoint ?
>What about having a report where every other data item has
>a different background color, can I do that?
Yes, little code for this… for the automated version, there is no AutoPilot either (but this is just a missing macro, not something you can’t do).
>One more: can I ‘snake’ the data? This is the case of
>mailing labels where the data goes down to the bottom of
>the page, then wraps back up to the top and down again,
>knowing that there are 3 columns per-page, and
>automatically calculating how many labels will fit on a
>page based on the label-paper type then paginating after
>that? Is it that paper-aware?
Since you can copy data to an hidden text or spreadsheet file, yes… In fact this is what we do for our accounting application.
We take an adress from one dbase database (managed by another OO.org application), when we take descriptions and prices from an hidden spreadsheet, and we make the invoice (unlimited number of pages with tables, headers, footers, etc). At least we make some reporting (costs and benefits, serial numbers, etc.) that we can print directly or inside a PDF (that’s basically the same for OO.org). So we join data from different sources and we make a complex multipage report. We even calculate a few things (add VAT, multiply price * quantities, separate services from hardware, etc.)
One week of development and many problems (grrrr, documentation is very poor), but no technical problems. Now, we plan to make a contextual help for methods (that will be placed under an Open Source licence of course). So next time it will be easier And with the work of other people I think it’ll be easier and easier and easier, etc. That’s the way Open Source Software works… It’s pretty difficult today but the community already begins to change that.
Of course many people will prefer to wait for more Autopilots and documentation, but today we are already happy switchers.
“Chances are you have some applications which you are going to rewrite them now or next year, because they contain old code difficult to maintain in order to acomodate your new business requirements. Right ? And you are going to develop some new software you need it, but you never used before.”
Business tends to take the approach of “if it ain’t broke, don’t fix it”. The only way many applications EVER get rewritten from scatch is IF it were cheaper to do a total rewrite rather than to modify existing code. Consider for a moment MOST companies have not a single programmer on staff. All of their programming gets done by contract labor.
To this day; I still have a pair of crucial DOS applications floating in our mix. Don’t laugh, it’s a lot more common than you might be ready to accept. Vintage 1990, and work perfectly for their assigned task. Written in Business Basic if memory serves.(I’m not a programmer)
I detect a lot bigger “wait and see” attitude in the business world all the time. Some are willing to stay the course with Windows, others are making moves. Most are just setting on the fence waiting to see where things are going over the next few years, running with what they have, developing as little as possible, and watching very carefully.
While there is currently a lot of interest in Linux, there is also a shit load of caution on the part of businesses getting fully involved with it. The mixed enviro will be with us for ages, and for good reason. Business by nature moves in very small steps, this one is no different.
The thing that scares me about Access and Excell is not the “core” and known applications. I did some work at a company where they had over 2500 MDB files on their server and they really had no idea where they came from who used them and if they were current.
They rolled Access out as part of office and everyone decided to automate their own jobs.
But the worst part, most of the people that developed these have now left the company, leaving behind people that don’t know what or how this application fuction, but they rely on them for their business to function.
Migration for this company would be impossible, but this is not due to the “lack” of an Access like tool, but because of very bad IT controls.
“That’s entirely incorrect. The 2 are bi-directionally compatible: VB6 ->> VB.Net via Interop and RCW’s, VB.Net ->> VB6 via RegAsm.exe. It’s quite simple and painless actually.”
OK, great! Most businesses should probably take that route.
There are simple alternatives:
Perl or some scripting language on back end to assemble and manipulate data.
Perl – PHP – whatever on the front end for reports, presentation and automation via intranet or internet.
A lot of big players on the Net – that grew up on the Net – have already gone this route to some degree.
BTW: it didn’t look “quite simple and painless” to me. Not a big OO fan.
That wasn’t where I wanted to go today!
I agree that Access is an exellent application – and there is no good open-source replacement yet.
But Access has two major disadvantages – and this is where Open Source could beat it:
* It’s quite expensive (You need a license for every client).
* It’s not server/web based. You can put the *.mdb on a file-server – but then it’s damn slow and you can’t use it from the Internet. That’s why Access looks a bit old-fashioned – i think people would prefer forms to be web-based nowadays.
I think a good Open Source Solution should not follow the same bad client-only approach, but rather be server/web based with generic connectors (XML-RPC?) for data interchange with office applications. And – of course – it should support the most popular web database – MYSQL.
A graphical query/form designer application, which interacts with the server via XML-RPC (to read the database-meta data and to edit form definitions) would also be cool. (Why XML-RPC? – because you can install it on any PHP-enabled web-server – and don’t need an open mysql-port).
Btw, i’m developing a php-script which reads very basic form-definitions from a xml-file. It can already handle foreign-keys (1:n relationships) and “sub” tables (for m:n relationships) are coming soon. It does not generate reports yet – but that should be easy to add. Anyone interested in helping me?
DABAXS Homepage: http://www.scheinwelt.at/~norbertf/dabaxs/
“* It’s quite expensive (You need a license for every client).”
Incorrect:
http://office.microsoft.com/en-us/assistance/HA011208861033.aspx
“BTW: it didn’t look “quite simple and painless” to me. Not a big OO fan.”
Interop/Regasm.exe have nothing to do with OO, indeed it’s entirely possible to create entire solutions in either VB6 or VB.NET w/o any OO paradigms whatsoever. How is it not simple? Regasm is a command line tool, and creating a RCW (runtime callable wrapper) around a legacy COM component can be done via the VS.NET ide, or via command line tools as well (typlib.exe).
This is a little OT, but Microsoft has a tool for just such situations as you experienced. It will scan your corprate intranet for .mdbs and provides rich reports about how many there are, when they were last used, and other things like whether they could be upgraded from old file formats successfully. Its free.
Access Conversion Toolkit:
http://www.microsoft.com/office/ork/2003/journ/accessconvert.htm
There is alreday a GREAT solution out there: http://www.realbasic.com. It also works with the MAC. I have ported several application with minor amout of work. I switch to mySQL from access and REALbasic from VB.
–Good Luck
I too was a developer in Visual Basic, with a lot of Access databases behind it. I maintain(ed) also some Access applications.
When I switched to Linux (first) and Mac OSX (later for the desktop), I faced the same problem. I missed a decent development platform and a decent database.
Now, I was at the time, already moving most of my applications to SQL Server because of the stability. The way I program included a lot of stored procedures. Therefore, when I switched, I looked at Postgresql. At the time, they were the only database on Linux (besides maybe Oracle which is out of my price league) that provided everything I needed. Today, they have 3 platforms available. Even Windows is supported (native in 8, through Powergres in 7.x)
For a GUI, I started doing a lot of development for the webbrowser. I mainly use Cocoon here. There are plenty of tools out there to do XML, XSL, …. I use Eclipse. Again, available on all platforms.
My biggest problem remained the rich clients. A couple of months ago, I discovered the solution too for that problem. I now use RealBasic. I’m very familiar with the language, since I used VB/VBA. Realbasic sits, imho, somewhere between VB6 and the first VB.Net when it comes to features. But, big advantage is that I have my development environment running on Windows and OSX (not Linux yet) and that it creates executables for Windows, OSX and Linux (GTK+ toolkit). With once source code, I can make the 3 versions.
So, that’s it for me. I have a new database environment, a new development environment but I didn’t lose anything of my knowledge. I know that the tools I use are not all open source, which is a pitty, but I have a working environment with decent and stable applications and a good user community.
Just my 2 cents ….
There is a Solution, not for Access, but for VB:
http://www.purebasic.com
A cross-platform Basic-compiler for Windows, Amiga, Linux and a Beta for MacOSX is also available.
Please, please do not port these horrors to Linux! Even if it means 10 more years or eternity for Linux to be more adopted because of it – just do not do it – I beg you! The goal just does not justify the means here…
1 – Rich Query: You can build a single Access report which is the aggregation of data out of an Excel spreadsheet, a SQL server, a DB2 mainframe, and a Windows SharePoint Services list. You can do this without writing a single line of code; it is essentially a giant JOIN.
from experience in building access DB’s I hate to think how unreliable this is going to be
2 – Rich expression service: the expression service in Access has built in calculation functions like Excel, but can also natively call SQL queries, run VBA code, and wash your car (okay, not the car). It is sort of a jumping off point, and engine which parses the bits of the expression and hands them off to the various components which rely on them.
[i]
except in practise it is a hell of a lot easier just coding in LAMP/LAPP
Just too many annoyning access bigs/limitations
[i]
3 – Wizards, Wizards, Wizards: Access is chalked full of wizards (which are actually Access Forms running VBA) for automating tasks for users, e.g. Mailing Labels
most of the time the get in the way
4 – Superb printing support: the Access designer for reports is entirely designed with the concept of printing (as opposed to on-screen viewing) in mind. All controls/content in an Access report are positioned in inches on the design surface. While to you and I, the thought of killing a living organism just to see sales figures is ludicrous, many business people still require this facility.
flip side of this is the export facilities are atrocious, basicallty to e-mail an access report they have to have either the same version of access or runtime
He mentions an Access application with 320 forms and over 86000 lines of code…
The company I work for have their VBA/Access development restricted to EUC (End User Computing) cells per major division. They have strict guidelines on how to develop apps. One of those guidelines makes sure that bigger applications are developed by specialised people in a decent development framework (.NET, J2EE, and even VB6) with a powerfull backend (oracle). This way, you never get such a bloated Access applications… not to mention the coding skills of them so-called developers.
I _know_ that those ‘developers’ won’t be able to adapt another language quickly. I think a migration path to JAVA is not the way to go. These are the only possibilitie according to me:
– port of Access to Linux (not very plausible)
– cross-over office
– wine (maybe even a specific ‘business’-oriented version that specializes in making Access developments work – even only runtime Access .mde’s)
And please, please, pretty please, in your company, provide guide lines, coding conventions, gui conventions and have a competence center ready for answering trivial questions … as should be the case already disregarding the fact that you might consider to migrate to linux.
Just my $.02
Companies are not on the same page as programmers.
Programmers think: how can I make this program run faster, smaller, more efficient.
Companies think: if it ain’t broke, don’t fix it, and why have you taken this long to fix a little thing like that? (because the programmer noticed how badly designed something was while fixing that little thing, and decided to tweak a little more)
I too have struggled with migration away from MS Access. I have developed complete applications in MS Access for the past 5 years. Personally, I switched to Mac and Linux, and I hoped to change some computers of my clients soon thereafter. I’ve studied this topic for about 2 years now, and although some applications have a goal of mimicking MS Access, I feel that the best option we have right now is to use java and/or a php or equivalent solution.
Consider this – I don’t mind learning a new language and API, if I know that it will be platform independent, have a solid future, provide solutions to all of my application needs, and for it to cost nothing except for my time is a welcomed bonus. I have worked with all types of languages, including java, c++, vb, mono, real basic etc… I have also played around with the Access replacement programs listed earlier in these posts, including OpenOffice.
I think that to bridge the gap from would-be converts (from MS Access), Java needs a solution to provide a ready-to-use widget set that mimics all Access widgets. I know that Java and Swing provide a programmer with just about anything he or she would ever want to do, but I don’t want to spend my time creating widgets – I want to spend it creating applications. Access widgets are familiar, and they have stood the test of time. I’m not even saying that Sun should provide this, I have tried some options from SourceForge like PSwing, JTableview, Java datepicker etc… but I would love for someone to make “VBSwing.”
As a personal example, I need widgets like comboboxes with multi-column options when expanded, and find-as-you-type entry. If Access developers knew they could learn a platform that has everything they are used to having, they would be more comfortable. Many people only use MS Office instead of OpenOffice because of MS Access. 90% of all the companies I service could switch away from Windows all together if there was a viable Access alternative.
Too many *nix savvy persons ignorantly comment that Access is junk, just like all other MS software. Only those of use who have made a living by producing work product from Access know that it is likely the best software MS has ever made. Microsoft knows it too, that’s why it isn’t included in Office for Mac. They also say that “java is slow,” but companies don’t care about client application speed. They want it to work, and Access is usually just a front end anyway.
For reporting, options do exist such as Jasper Reports, and some others that are based on Jasper. I have replaced about 40% of all my Access applications with LAMP (Linux Apache MySql PHP) solutions. I use a free reporting library called fpdf which allows me to generate pdf’s on the fly. It’s funny, but most people tell me they feel more comfortable using a php web based solution than a custom stand alone client app. The biggest reason I haven’t focused on java is because of the time it takes to do simple things, like get the widgets to do what I want. It’s easier for me to have my users put up with the limitations of web forms. It’s easier for me to make some DHTML magic for what I want, than to have Swing cooperate. I’m not necessarily knocking Swing, this is just based on my ability and success rate.
…sorry so long – I take this issue personally
One Issues with why VB6 is used is because it easy to use and understand move to java or vb.net is like trying to pick up new lang. rewriting all program that you have vb6 may be inpostable or just to hard like program that may have took around week may take a mouth or yeah to develop. I found it was easyer to learn g++ programming system then lean java. but secound issue is that it ok to said just port every thing over to java or .net but what if client is using windows? Java run that slow and is so buggie under windows xp that really no point. most clients would not have java and it may too hard for them to get and install java and what if client has older or new copy. the program can not work or actting incorrect. good e.g of this is a chat site I was using I update to java ver 5 and rooms where not able to load so I had wait about 2 weeks for them to fix it