Linux.com

How do these guys handle all the macros in excel files, and the use of ms access db, both are widely used here and that is preventing me from switching.

#

I would imagine that the Excel macros would have to be rewritten into OpenOffice Calc spreadsheet macros. From what I have briefly seen, they are very similar.

As for Access databases, they have always been considered wasteful and redundant since they are almost always populated with data that already exists in a bigger, more complete database. It's just more efficient to query the bigger database directly, rather than create an Access database, fill it with existing data, and then query the data in Access.

I don't mean to sound as if I'm knocking your IT procedures. You know what works best for your company. It's just that there are ways and reasons to switch to open source, and switching will probably make your business more efficient too.

#

Not the same guy as the parent poster BTW...


    In my case, we are a small firm that has only an Access DB driven management system for tracking jobs, inventory, worker tasks, quotations and shipping. It does everything except for our accounting, which is taken care of by another application...


    We have no choice but to use this system, in fact, in our case there is nothing available (That is complete and in our price range) that uses something other then Access for its back-end. I spent a better part of a month looking at various packages and none of them fit our needs and price range that was 'open' or used something other then MS Access for its backbone...

#

You may want to take a look at Rekall from TheKompany. This is an Access like front end that will use something like MySQL/Postgres, etc as the backend. TheKompany has released Rekall into open source.

#

This may help - Access 2000 runs quite well under Linux using Codeweaver CrossOver Office product - http://www.codeweavers.com/

I could run vba code, reports, queries very well, no bug messages.

#

How does this help him move away from using Microsoft Office if you are just telling him to run Microsoft Office in Linux? That doesn't help!

#

It opens the door. Is he running ms office on linux? It doesn't appear that he is. Getting the GNU/Linux into the door is the first step. His company realizing the uptime/stability/total cost of ownership savings is the next step.



After that, it's all downhill from there.



There's no urgency, hard sell, or all out lobbying necessary with GNU/Linux anymore. The companies are realizing this more and more on a daily basis. The small and mid size business segments are reflecting this in linux server sales, and the daily announcements of governments foreign and domestic, states and localities are all contributing to the buzz.



High profile switches from ms office and from ms servers and operating systems are piquing the curiousity of business owners in the smb segment, and are making enterprise CIOs think twice on whether they should sign that long term onerous ms contract when their competition and others in their industry segments are making FOSS announcements. Is the CIO going to make a costly mistake in continuing to stubbornly ignore FOSS? Is this going to come back to bite him in the ass later?



The guy's company may feel that office is necessary because of access, and ms will do everything to perpetuate this myth, but at some point in time, the guy or his company will hear of others in their situation or using access for similar purposes who have successfully made the switch. In the meantime, they may have made the migration to the linux operating system. And picked up the necessary support and contacts they need for further migration.




Don't knock ms office on linux. That's how quite a few businesses will begin their migration. And that's how the application developers will realize they should be building for linux, not for emulation on linux.


MS office is very often touted as THE application that holds businesses back. It may be true in a lot of cases, but I'd say there are more specialized applications specific to particular industries that hold the key for the majority of desktops in a business.

#

when i started working at my current job, our database was MS Access. I quickly changed that and ported it into PostgreSQL. THere is a tool called pgadmin that will take your Access databases and port them into Postgres, a real database. It takes a little work, but it is worth it. unfortunately most of the people are completely stuck on using MS Office and I haven't been able to get them to switch, but maybe 1.1 will finally help them see how much money they're wasting.

#

I would first migrate your VB/Access applications from a local/shared Microsoft Jet database to a Linux database, using MySQL or PostgreSQL, and their Win32 ODBC client software. This offers many advantages, including making your data more accessible to other technologies, and the exercise of making your data/tables more SQL-compliant/portable.

After the data migration and the relinking of the tables to point to their ODBC counterparts, then you can and may consider using an alternative, open source application to replace the VB/Access application, if that is even necessary. After all, it is more about managing the data (value) than it is about the software (expense).

#

"...then you can and may consider using an alternative, open source application to replace the VB/Access application."

Like What? Someone mentioned a new open source application called Rekall. Does this, or anything else, have a query-by-example (i.e. query grid) feature to easily build SQL-like queries of the data residing on MySQL/PostgreSQL? Not to mention the whole application design and reporting interface that comes with Access. Access may not be perfect, but it exists, it's here, now. OS advocates all talk up the replacement for the Jet Engine, and that's a good thing. But where's the rest of Access. Access, love it or loath it, is a rich, useful application for many people. And part of the reason is the interactivity available to end users. Sure you can use PHP or whatever to create a turn-key front end, but users need to roll their own queries and just throw data around in results tables, for a variety of reasons. When there's a front end that allows me to wizard my way to a crosstab query of my data, then I will move to OS for all my database needs. In fact, I can't wait! Incidentally, the OpenOffice group has an Access-like DB as an upcoming goal, but I wouldn't expect to see it for about 2-3 years. I'll be the first one to switch when it arrives, and the sooner the better.

#

http://fabforce.net/dbdesigner4/

I think the better question is: Does anyone actually look for the answer?

#

OS/2 wars post!

#

Short answer: Yes, Rekall does that.

#

I think a lot of you guys are knocking Access for the wrong reasons. Your complaints that Access is not a "real" database ignores the obvious strength of Access, that it is a simple to use program for small workgroup-level applications. In fact, this is ALL Access was ever meant to be. Businesses that are creating mission-critical apps on Access are doing so because they can't afford to do it in another program and/or they find Access easy to use and the "real" databases daunting. But please, don't blame the product for being mis-used. Instead, blame the dearth of easy to use alternatives.

#

"Businesses that are creating mission-critical apps on Access are doing so because they can't afford..."

Can't afford?!

Ok, you've just justified the move to Open Source. Kudos!

#

Thats not the point. They cannot justify hiring a programmer to make an app to replace what they already have running in Acess. Don't get me wrong - I HATE Access, it is much easier for me to work in a 'real' SQL92 compliant database with industrial strenght features than that cobbled together monstrosity called Acess. I would prefer to build web interfaces for PostgrSQL with Zope or PHP. BUT if you have an existing app that works, any other platform will require that you go though the expense of development.

#

Access is considered a joke because it tries to do too many things, each of which, poorly. It encourages bad practices such as co-mingling of data, business logic, and presentation. It employs a lock-in strategy, no wonder so many people are having trouble escaping it. And sorry, but the elaborate misuse of Access was part of the marketing. Yes, you can read where it is designed to run with 256 concurrent users or that it is secure etc.

You hear, ' I can't move to oo cause I got all this access code/data/reports'. Do you ever hear 'geez, I would migrate from mysql to postgres if there was only a way...' No. Take this as a lesson.

#

Do you ever hear 'geez, I would migrate from mysql to postgres if there was only a way...' No. Take this as a lesson.



You are absolutely right! Feel sorry for those whose eyes are blinded by M$ lock in and think it is great!

#

OO.o supports an Access like system. The caveat is that you have to use a real DB on the backend. The latest edition will link directly to a MySQL DB or any ODBC compliant DB.

Steps on a migration would work something like this.

1. Install MySQL or PostgreSQL


2. Create a DB to house your current Access DB


3. Setup ODBC connection into said DB


4. Launch Access and add a connection to new ODBC DSN


5. Start moving tables over to the new DB


6. Relink forms to use the ODBC based tablespace (this gives you something that continues to work while you do the next step)


7. Start redesigning the forms in OO.o's forms system linking against new DB tablespace

It is obviously going to take a bit of work to do the conversion, but you've already got all the logic sitting there, you just have to convert it to OO.o's syntax.

#

I thought Access is a single user db. Does it support simultaneous multi-client connections? I was under the impression it does not.

#

Access will support multiple simultaneous users. The problem is perfomance. Depending on a number of factors, it might get slow after 5 users or so. And you have to be careful about how you do record locking. But it can work quite well in a well-designed system. For large workgroups and large recordsets, you will be better off using Access as the front end and moving the data into Microsoft's SQL -- or better yet into a good backend like PostgreSQL.

#

It is possible to use Access with multiple shared client connections.

Unfortunately there are a lot of race conditions and the system will routinely fall flat on its face if you have more than a handful of users (or even if you have 2 heavy users).

#

Dependency on Access programs/databases doesn't mean you have to spend money on Office licenses. You can just get an MSDN license (or Access developer's kit - if it's available) and run your Access databases and forms on the freely distributable runtime. You only have to have 1 copy of Access for maintaining the application. The only restriction is that the users running the app under the Runtime can't open anything in Design mode, or open raw tables, but that is usually preferable if you Access application is well designed.

#

I feel your pain. As the owner of a small store that requires specialty software (consignment) and an IT guy who has actually worked for a database company in tech support, I think I know whereof I speak. The prog I have to use only comes in Access. I've begged for the guy (who has sold more than a few hundred copies and keeps it updated) to convert to something like Pervasive (Btrieve) just because I know it is more stable and loads faster. He doesn't want to be bothered. There are other consignment software progs out there but none that operate the way I want the software to work and be stable.

Effectively, like you, we have no choice but to use this app with Access.

#

Email me at gtcopeland2002@yahoo.com. Converting your database to PostgreSQL, which is freely available, would do wonders for performance and reliability. Using Access as your front-end is acceptable even though not preferred. If you truly want to talk about other options, email me. A migration would increase scalability, performance, and reliability, while giving you more options for backup and increasing uptime. Best of all, it opens the door for using any number of additional tools to readily create reports and manipulate data; which may or may not be a "good thing", depending on your perspective.

#

I am an Access developer, and have made my living as such for quite awhile.

There are many Pro's and Con's to Access. Much of what has been said here is absolutely true.

That being said...One thing Access has that I have yet to see any other product do as well is it's lightning fast developemtnt times.

This is both good and bad, as it can lead to some really silly stuff. But at the same time, in my case, I can produce OLAP tables/ analyse large chunks of data, and put together VB looking somewhat secure front-ends faster than any other developer using any other tool.

I do not do enterprise-wide applications, cause my toolset is not designed for it.

If you need it done quick and dirty, don't want to spend and arm and a leg, and it's not an enterprise application. MS access coupled with and MS SQL server has no match as far as developement speed, and ease of use.

I am heartened to see some of these opensource projects beginning to venture into this workspace however. And would be very excited to see another viable option that allows me to do what I do now with an opensource license.

#

MS Office macros rarely exist outside the computer magazines in my experience. In any case, oo.o's macro language looks very similar to vba.

#

Actually, I used macros to automate printing out customized phone listings for a company I used to work for. They also automated maintaining entries, among other things. Properly applied macros can be a real time saver.

#

Hi,

Is there any kind of report on why they switched, such as a white paper, pdf, financial analysis? There is a group at my LUG who are trying to convince our local government to start using open source and any kind of reports would be useful. If you can post links as a reply to this message, I'll check back later.

Thanks,

Brian

#

Not long ago the city got to go through a shakedown by the BSA. After having to pony up unexpected millions of dollars, one really does learn to appreciate software that isn't going to require license tracking. People have better things to do with their time than going through a discovery process of exactly where every piece of software came from on every machine gathering dust in closets.

#

"The city is broke" comes to mind.

Chupa

#

i don't have time to look for them now, but i remember several reports on the advantages of OSS for the public administration.
There's one of the EC (european comunity), one of one british public institution, one of a swedish one and one of a spanish one.
these are the ones that i can remember of.

I think that if you look carefully you can find a

I found this link!
The IDA site:
http://europa.eu.int/ISPO/ida/jsps/index.jsp

Look at The IDA "Open Source Observatory"!
[follow the link on the left of the page]

Note: IDE= Interchange of Data between Administrations is a part of the European Commission

#

I did a report for my company a few months ago when i talked about using Microsoft Windows and Open Source solutions which looks like what Austin is doing.

Here is the report

http://www.geocities.com/rjdohnert/opensourcewind<nobr>o<wbr></nobr> ws.pdf

Click on the Open Source Windows link to read it.
If you wish to contact me about the paper and or have any questions regarding our use of Open Source Software on the Microsoft platforms go to the main page to contact me.

http://www.geocities.com/rjdohnert/

#

Page that it is located on is

http://www.geocities.com/rjdohnert/computer.html

#

300 of 5000 is 80%? Which is the misprint?

#

Read the article. It says the 300 will be the first to actually convert.

#

It was talking about a department being the first to roll out on 300 desktops, not 300 being the total.

Read a little more carefully next time

#

Your interpretation is. The first group to move (Communications and Technology Management) has 300 desktops that are moving to OO. The other portion of the 4000 (80% of 5000) would be following later.

#

Actually, neither 300 nor 5,000+ is a misprint.

300 is the number of desktops in the CTM department, not 80% of anything. The city in total has more than 5,000 desktops.

But there was an error in the original story that I've now corrected that is related. I wrote that 80% (of the 5,000+ desktop users) "will be" migrated to OO.o. The correction is to change "will be" to "may be." Decisions have yet to be made about other departments.

#

this is a plea to those who respond to migration concerns regarding MS-Access to NOT just say "move your data into postgresql!" or mysql or whatever.

the problem is not with migrating the data, it's migrating all the business logic, complex dynamic forms, reports, etc. that's bound up in the typical MS-Access business application.

it really makes F/OSS users seem out of touch.

#

You might notice I didn't give just a quick "move things into a real DB" answer in the other thread. I did list out a series of steps for doing a migration knowing fully well what would be involved in the process.

The problem that I've found most people face when it comes to this is an unwillingness to even look at the available options. OO.o has an Access style front end. It's not as advertised because it relies on a real DB being on the backend and most people are afraid to try something like MySQL (which is very simple to install and get up and running even on Windows) because they "don't understand DB's". Well, if you don't understand DB's then why are you creating one in Access, it's a DB system as well.

#

Where trying to centralise all our database and what we're doing is 2 phase.

Phase 1: Move all the data into a database and have access use linked tables.

Phase 2: Build a web portla/interface with a single sign on.

Will still end up with users making stuff in Access but as time goes on it will be merged with the portal.

Personally I think it's the best solution.

#

"the problem is not with migrating the data, it's migrating all the business logic, complex dynamic forms, reports, etc. that's bound up in the typical MS-Access business application.<nobr> <wbr></nobr>... it really makes F/OSS users seem out of touch. "

So with Access the business logic, complex dynamic forms, reports etc. are all mixed in irretrievably with the data?? Wow this really makes Access users seem completely out of touch with database design and management.

#

As a F/OSS avocate, I hate to do it; but I must agree with the concerns of those who wish to evacuate Access databases saying 'it's too costly (time) to do it. I just can't understand why some here don't.

If window managers weren't made more user-friendly and KDE and Gnome hadn't come into existence, many users now enjoying a non-MS OS would have never made the leap to Fvwm or GNUstep.

F/OSS developers are constantly looking for how to make things easier, the first to create a almost-fool-proof method of converting Access to MySQL/PostgreSQL AND the queries, forms, business logic to PHP/XML will truly have many a database user giving thanks to their contribution.

Rather than just attack those wanting to convert because they note difficulties in the process, help by pointing them to possible resources, or by directing them to those request forms that exist on project websites asking how to better the program. Don't belittle and chastize those who WISH to convert, for there are plenty in the ANTI-F/OSS camps who will capitalize on your foolishness and you will have driven another would-be convert away.

Listen, don't just hear.

#

So with Access the business logic, complex dynamic forms, reports etc. are all mixed in irretrievably with the data?? Wow this really makes Access users seem completely out of touch with database design and management.

I'm going to assume you're being purposely obtuse here.

I simply meant to say that when access users worry about leaving behind their Access DB's, it's not just the data tables they're concerned about: it's all the effort they've put into building applications using the Access tools/interfaces that *cannot* be easily converted to another format.

the *data* part is, of course, fairly easy.

#

"the *data* part is, of course, fairly easy."

No, it's not.

The problem with Access - the reason why most geeks hate it - is that it makes it look simple. However, almost every person I've seen try to make an Access database has wound up creating more problems than they solve. They don't understand the concepts of data integrity, and therefore create these really funny tables that get screwed up all the time, because of improper data integrity constraints.

Most of these have all fields as varchars - even the numbers! Those with keyword fields have just about every spelling and capitalization possible. It's a complete mess, and usually requires many, many IT support requests to find out why their database isn't find their data.

If you have the data in there right, most of the business logic falls in line pretty easily.

I have found the following to be a near-universal truth:

If it's small enough Access, it would probably be much easier to do it with a spreadsheet, anyway. If it's too large for a spreadsheet, you need a real database anyway, and Access is only going to cause you pain.

#

The problem with Access - the reason why most geeks hate it - is that it makes it look simple. However, almost every person I've seen try to make an Access database has wound up creating more problems than they solve.

agreed, but my statement was that migrating the data was easy. not normalizing it and otherwise cleaning it up.

#

Oh yes we do!

One of my clients (2000 seat intranet) had the good fortune to ban Access when they took the all M$ route a few years ago. The IT department already knew that they couldn't provide support for what they called "spaghetti code". They chose Filemaker Pro instead.

There are tools and reports of converting those fancy forms to pgaccess. You can also use Java.

#

I really like Linux, and I like the idea of having a real database to use, but I cannot stand pgaccess. I sure hope that's not the best we can do!

#