Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm a Java EE developer and was just contacted by someone who wants me to put a quote together for an application for his business that can integrate with their MS Access "backend".
I was hoping to post this and just get a general high-level overview of best practices involved with MS Access Programming. I assume the program would be entirely in VB, but didn't know if I would have the option of writing something in VB.NET or (preferably) C#.
Also, I despise the presentation layer: any good GUI-builders for Access applications?
What are some common tools and APIs (unit test frameworks, build automation systems, etc.) that MS Access programmers frequently use?
Any links or resources you would recommend?
It sounds like a pretty simple application: take inputted data, compare it to some tables, and throw some output to the screen. I'm a pretty decent programmer so even though I've never done an Access program before it couldn't be too difficult for me to pick up.
Thanks for any thoughts or suggestions!
Access as a front-end
Well, people feel strongly about Access. The main reason for the negative view is that it is widely used by non developers who have no concept of proper database development and end-up with these barely working, horribly designed applications that bring dread into the heart of developers.
Having said that, Access is nothing more than a Rapid Application Development tool with a very low barrier of entry.
The good and the bad
Access is a fairly old product line, spanning almost 20 years. A lot of people's objections to Access as a technology are grounded in its early history: since backward compatibility is something that Microsoft deems important, Access has retained most of its features, good or bad, over the years.
You can see the choice of VBA, non-winform forms, promotion of modules over OOP, to be bad choices, but the continuity of these early-on design decisions have made Access a stable platform to build on.
VBA: is the language that never dies. It's clunky, outdated, lacks recent advances in languages, but it's also fast, simple to learn, flexible, easy to interop with (for instance calling Win32 APIs is really simple), and it can be interfaced with external libraries (event written in .Net).
Bound forms: by default Access makes it easy to create working applications without a line of code. Most queries can also be created without having to go down to SQL at all. If you're a control freak, it can be annoying, but it's easy to drop down to code and control everything from there.
Third-party integration: even though there are lots of add-ons to Access, I wouldn't recommend using most of the user-controls or third-party libraries unless you really have to. They can be very hard to deploy in environment with limited user rights and versioning can become hairy.
Ribbon: it may be good or bad, depending on who you talk to, but Microsoft has invested a lot into it and it'll probably be there for a while. At least the Ribbon and the improved controls in Access 2007 and later make applications look and behave in a modern way. Gone the horrible UIs of old, you can now do really pretty things with themes, HTML layouts and a modern ribbon.
Reliability
Most of the objections, especially about reliability, are simply no longer true.
A carefully designed Access Application can support dozens of concurrent users. I have a decent-size application managing Procurement/Stock/Quality/Parts/Projects for a manufacturing company that has 150 users, of which usually 50 are connected at any given time. I haven't had any corruption in years.
Of course, you must always bear in mind that Access is a multi-user file-based database, so you cannot expect it to work without risk in environments with unreliable or slow networks, and connecting to a an Access backend through WiFi is really asking for trouble, just like you wouldn't work on large Excel file over wireless either.
Maintenance is part of the lifecycle of an application. Preventive maintenance is extremely important.
Don't wait for something to go wrong: build some admin tools within your app that will help check the state of your data (make sure everything is coherent, detect invalid user inputs, etc).
Also compact the database regularly (I do it nightly after I make a backup as part of the daily automated tasks on the backend server).
Some random tips
Make sure your front-end and back-end are split: only data should be on the backend, and the front end should be installed on each user's machine.
From your front-end, open a permanent link to a dummy table on the database back-end: keeping an always-on connection will greatly improve performance. For the reason why, have a look at this question.
The backend should be in a shallow network share (don't put it deep under multiple directories).
Make sure you think hard about how you will deploy your updates to all clients automatically.
There are many ways to do this. I developed my own but you could use ClickOnce or Tony Toews's Auto-Front-End Updater
Use the Runtime: your front-end application can run without users meddling with its internals if you deploy the Access Runtime on their machine. It's free too.
Don't fight the tool: Access has a certain way of doing things. Just use the tools available without going to code until you have exhausted the capabilities of the RAD environment. You may be surprised by how much you can achieve without any code at all.
Nothing stops you from using OOP: defining classes and binding your classes manually to your forms, controlling data updates, etc. The default behaviour in Access tends to encourage quick-development and is fine for small projects, but if you suspect that your project might grow, plan for the future, just like you would with any other framework.
Access as a backend database
Now, if you want to use a front-end written in something else, say C#, it's fairly easy to use Jet/ACE drivers to connect to an Access back-end database.
Jet is the older driver for Access and only supports .mdb files. 32 bits drivers are installed by default in Windows (still there in Win8) and can always be relied upon.
ACE is the new .accdb format used by Access2007/2010/2013. It has increased limits and enhancements over the older version but it can still talk to an .mdb.
You will have to install the Microsoft Database Engine on all the clients (not necessary if either a full version or the Runtime of Access 2007/2010/2013 is already installed though).
Don't try to use 64bit versions of Access/ACE driver. It's the future but it introduces many new issues, especially if you are using 3rd-party libraries or some of your clients have 32bit Office installed (your can't mix and match 32bit and 64 bit office components).
Similarly, don't build your C++/C#/Java/Python front-end app in 64bit mode and expect the 32 bit ACE driver to work. Keep everything in 32 bit, make things work, then test 64 bits versions if you really need to.
Do always keep at least a single connection open to the back-end database from your code, as mentioned above.
Ideally, try to abstract any Access-specific code to make it easier later in case you need to switch to a server-based database. You could use an ORM that can talk to different back-ends transparently, or you could at least separate your SQL queries into resource files or separate objects that can be easily replaced later.
Depending on the load (mostly how much data need to be changed in the DB), an Access back-end can easily accommodate between 20-100 users without issues. Things will deteriorate if there are lots of insert and updates occurring all the time. There are lots of tricks that can be used to make things better and make Access scale well, but you are inherently limited by the type of application your are building and how users are accessing its data.
Related
I am looking for a simple, no frills, docker-compose based solution so I can start playing with some common tools, without having to devote lots of time into learning to configure the infrastructure. It should pull from the official images of the included projects, to make things super standardized and easy to move forward.
Ideally, I can have local directories mounted, so I can just edit my code directly, and have it served up through the container. Even better is to have the database stored similarly, in case I wind up liking it and want to port it into a project.
Edit:
Since it seems nobody gets it. The reasons for wanting this are:
No local installation of tools to pollute my development environment.
No rebuilding of containers as I change my code, learn, and test out features.
Not using any exotic features or special configuration, so official containers from the distributions should be sufficient.
Clean roadmap to scaling up to a real project. Acts as a template going forward.
Not spending time on tasks that are not relevant to the final goal (configuring a platform that may never be used).
It seems clear to me that a significant portion of development should use containerized runtimes for building/testing, without installing things on the real host. That would avoid a lot of hassles and conflicts, and allows easy revisiting of old development environments.
This seems like an obvious thing that should be readily available, just like the standard images that many projects provide.
As I am just looking to evaluate things, I'm not that picky about tools. A development language/framework (Node.js), a database (MySQL), and web server capability (anything). If it's PostgreSQL, MongoDB, whatever. I just don't want to spend days wrestling with setting things up, before I actually get to start evaluating the platform.
I tried asking this over on DevOps a few days ago. All I got was one snarky and unhelpful comment, which has since been deleted.
I have tried following a bunch of different tutorials around the web and answers given here, but they all fail, and I really don't want to get sidetracked debugging them.
It seems like this would be a common template for starting many projects, regardless of complexity or expertise. So, I'm really surprised I can't find it. It also seems like a good way to lure in new users, which should incentivize project maintainers to have these.
I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
I've got to convert a not terribly complicated bespoke project management system from MsAccess Application to PHP/MySQL. I've been programming for donkey's years but embarrassingly know practically nothing about modern methodologies.
So the old 'learning curve' versus 'improved efficiency' conundrum rears its ugly head once again.
Although I've Googled up some stuff I don't want to prejudice your suggestions, where would you start, I'm at your mercy?
What sort of learning curve am I looking at?
Consider learning a PHP framework and its philosophy and architecture to produce the application. You'll be glad you did.
http://www.phpframeworks.com/
Basically, this will help you get up and running quickly with all of the necessary moving parts, in a way that promotes best practices. IMO it's probably the quickest and best way to accomplish your goals.
For recommendations on which one to choose, have a look here:
https://stackoverflow.com/questions/184395/what-is-the-best-free-php-framework-working-on-shared-hosting-and-why
Well, when you say you been writing code for years, do you have any choice as to the final platform?
Access 2010 can create web based applications that scale horizontally in a HUGE way. The resulting applications don't requite Silverlight or even any ActiveX, but ONLY a standard browser. Here is a video of a application I wrote in Access, and note at the half way point I switch to running in a browser.
http://www.youtube.com/watch?v=AU4mH0jPntI
Access 2010 also now does have database triggers and stored procedures. However, you are hinting that you don't have a choice of technologies here so the above new features and even the new Web site creating ability of Access is thus moot for you.
I guess the 1st area I would start with is installing and setting up MySql. The MySql site has some good links to tutorials etc. You simply have to get up to speed with that database server and get conformable with it regardless of learning PHP anyway, so that one step and area I would start out with. And, if you worked with databases, then you find MySql quite easy to get up to speed with so you feel like you making some progress as you embark on this new road
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Recently I found out that the company a friend of mine co-owns uses 4D, which I've never heard of before. They swear by it, but they're non-technical and what they say about it sounds like memorized marketing blurb. Unfortunately the 4D website also seems devoid of any actual information and is filled with words like "comprehensive", "solution", "platform" and "integrated" instead.
Since that thing is rather expensive and uses a custom language that I don't have much inclination to learn just for one project, I'm cautious about it and I'm wondering if anyone had any experience with it? Would you recommend it? What is it good for? What competitive advantage would I gain by learning it as a programmer, or using it as a company?
4D has been around for a long time (~25 years), so it's much older than e.g. MySQL. Think of it as a professional version of Microsoft Access: It has its own Pascal-inspired host language, its own relational database engine, a very mature IDE for rapid GUI development and a custom runtime which allows for true "write once, run anywhere" (anywhere being Mac OS (X) and Windows, that is). Nowadays, it also understands SQL, there's a server version and even an integrated web server. It's fairly powerful, so the comparison to Access probably does not do it justice.
Today, I believe it's mostly used for legacy apps which are as old as 4D is. I don't think I would learn it again today, much less start new projects with it, since you can get the same functionality and then some by stacking up open source components.
I used to do some very serious 4D work, one of the systems I wrote is still in use as an enterprise system about 16 years later. I got frustrated because they were taking years to come out with the new object-oriented version of the language and I was writing thousands of lines of code to use a third-party table control.
4D delivers cross-platform, very high-performance client-server systems using a proprietary server. The database model is much more set-oriented than SQL and pulls the sets all the way into the core language. It does a nice job of delivering code to the clients because it compiles all procedures to native code which is cached locally and updated on-demand when it is out of date.
The language and GUI environment have their quirks but the flip-side is that there will probably be a good living to be made from supporting it as a legacy platform. if you can get someone else to pick up the tab for the tools, it may be a useful addition to your consulting toolbox. You have to consider how much business-specific code is gonna be out there for a unique product with that long a history!
An engineer for whom I have huge respect was recently hired by 4D which says a lot about their commitment to the future, hiring this kind of guy.
I've been working a lot with legacy systems recently, doing a port from old Mac stuff to WPF and the contrast between the mostly-unused complexity of Visual Studio and old Mac tools reminded me of 4D. I'm also porting my OOFILE C++ database and reporting frameworks to REALbasic - the OOFILE set-oriented operations came directly from what I loved about 4D and this too made me think I was too harsh in this answer originally.
The thing to remember about 4D is that it was set-oriented from the beginning (written by a mathematician) and much easier to use for many things than SQL. The deployment model of 4D Server is a superb combination of desktop app and network provision - compiled components are cached on the server and automatically sent to a client when needed. There's no need to shutdown or actively push or deploy updates. The GUI model of 4D was frustrating but looking at the site today, they have solved most of the issues that I had to use third party solutions for years ago.
Avoid it like the plague. My company uses it and it's just a constant exercise in frustration. It performs no where near as well as the sales pitch would have you believe, and documentation is either non-existent or not helpful.
In my opinion, there is no reason to begin learning 4D unless you want a simple database app and are unable or unwilling to learn how to create GUIs in a bigger language. The main advantage that 4D has is that the built in functionality between the UI and the database can handle most of what is needed. If you want something quick, small, and inhouse, you can get by with 4D but if you need to develop a powerful commercial application you will run into a few walls. If you need something that 4D doesn't provide automatically it will be very difficult to get it working.
I consider the language completely archaic. It works for what it does but our product has become limited by the language and database itself. We keep running into weird quirks and have to code our way around them.
I have experience in 4D 2003 and 2004 but we haven't upgraded to the latest version because of the costs. It is extremely expensive. Each customer needs to buy licenses for each computer that needs to run the software. Our product costs over $1000 for a new office because of the licenses. When a new version of 4D is released every single customer has to pay to upgrade their licenses.
After looking at https://www.4duk.com/products/ataglance.html, I'd recommend you stay clear - it looks like one of those products that's going nowhere.
It reminds me of the time I was made use a development platform called Witango - absolute nightmare to use, and all apps had to be rewritten in .NET very shortly afterwards.
Invest your time learning something more mainstream/employable.
Avoid at all cost. 4D used to be a good Mac database twenty years ago but is obsolete today. Extremely expensive to deploy and poorly supported. I have used it for many years and have since moved to Real Studio for cross-platform database development, which has a more modern language and a far more active developer community.
I'll be wary of investing too much into something like this. On the good side, if that's what your company uses learning it will pay dividends. But the skills you learn will be hard to use in other places.
I think more than half the replies over here are inaccurate. I know of more than 20 companies with over 1000 users. And I believe there are a lot more.
With 4D v12.1 (www.4d.com) you can easily deploy at the click of a button for single-user, client server, Mac, Win. And there are easy to setup plugins for integration with Flex, iPhone and Android OS. Their KB and documentation is very neat and comprehensive.
They have a great engineering team and the support from 4D and the online community is just fabulous. I have been using 4D for several years and I have no complaints.
4D as someone else pointed out gives you a fully integrated backend database and frontend. The client server connections are stateful so you dont need to worry about record handling and client server session handling.
At less than $1000 per year it is not expensive and you can deploy unlimited single user apps. Which other propreitory development platform gives you that?
I am sure Real Software has its Pros and Cons too. There are many choices nowadays and there are many ways to skin a cat.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
In evaluating different systems integration strategies, I've come across some words of encouragement, but also some words of frustration over BizTalk Server.
What are some pros and cons to using BizTalk Server (both from a developer standpoint and a business user), and should companies also consider open source alternatives? What viable alternatives are out there?
EDIT: Jitterbit seems like an interesting choice. Open Source and seems to be nicely engineered. Anyone on here have any experience working with it?
BizTalk Server's key benefit is that it provides a lot of 'plumbing' around deployment, management, performance, and scalability. Through Visual Studio, it also provides a comprehensive framework for developing solutions, often with relatively little code.
The frustration and steep learning curve that others mention often comes from using BizTalk for the wrong purpose and from a misunderstanding about how to work with BizTalk and message-oriented systems in general. The learning curve is not as steep as most people suggest - the essential part of the underlying learning actually focuses on changing thinking from a procedural approach to a stateless message-based approach.
A drawback people often cite is cost. The sticker price can seem to be quite high; however, this is cheap in comparison to the amount you'd spend on developing and supporting features on your own.
Before you consider alternatives, or even consider BizTalk server, you should consider your organization's approach to integration and it's long term goals. BizTalk Server is great in cases where you want to integrate systems using a hub and spoke model where BizTalk orchestrates the activities of many applications.
There are other integration models too - one of the more popular ones is a distributed bus (don't confuse this with the term "Enterprise Service Bus" or ESB). You can also get BizTalk to work as a distributed bus and there are alternative solutions that provide more direct support. One of the alternate solutions is an open source solution called nServiceBus.
When considering whether to use a commercial product like BizTalk, verses something else (open source or developed in house), also consider maintenance and enhancements and the availability of the necessary skill-set in the marketplace.
I wrote some articles that go into more detail about the points I discussed here - here are the links:
Why BizTalk?
Top 10 BizTalk Mistakes
Extensibility Features in BizTalk Server
Open Source Integration with nServiceBus
My experience with BizTalk was basically a frustrating waste of time.
There are so many edge cases and weird little business logic tweaks you have to make when you are doing B2B data integration (which is probably the hardest part of any enterprise application) that you just need to roll your own solution.
How hard is it to parse data files and convert them to a different format? Not that hard. Unless you're trying to inject a bloated middleware system like Biztalk into the middle of it.
As a BizTalk consultant I have to agree at least partly with Eric Z Beard, there are a lot of edge cases that take up alot of time. But quite a few scenarios are handled extremly smooth as well, so it all depends IMO. But when you (Eric) call BizTalk bloated I have to disagree! We've found that the performance and reliability is excellent, it's flexible and comes with a lot of good adapters out of the box.
BizTalk needs to be used correctly,
I am a BizTalk developer and my experience with BizTalk is quite good.
Its reliable, performant, scalable, contains a lot of built in architectural patterns and build in components to make integration easy and fast, you get security, retries, secondary transports, validation, transformation etc... and what ever you dont have build in with BizTalk you can easily customized with .NET code, its basically a hard earned integration system and you get all this in one box.
BUT you need to know how to implement BizTalk correctly, not once I came across solutions that where implemented and often also architected incorrectly.
but the real benefit of BizTalk is that you can implement small solutions and scale up whilst most other integration systems from big vendors will only sell a whole integration pack which can cost much more.
BizTalk is considered the most complicated server from the house of Microsoft.
So any body saying BizTalk is not good dosent know BizTalk period.
We evaluated BizTalk at our company and were really disappointed.
We are using IBM WebSphere Transformation Extender (which has lots of (other) problems, too) and the mapping tool of BizTalk is a joke in comparison to WTX.
The graphical tool is not really usable for complex mappings (we have schemas with a few hundred fields in repeating groups) and if you do more than the usual "concat first name and last name to name" mappings, you will be tired of the graphical approach (for example the arguments of the functoids in the graphical mapper are not labeled and the order in which you connect fields to these arguments is important).
The XSLT-Mapper was usable but not really convincing, and even the microsoft rep told us to use a tool like XMLSpy for XSLT and load the resulting XSL file into BizTalk.
A third approach to mapping is to use C#-Code for the mapping, which was not acceptable for us as a general approach (we don't want to teach everyone C#).
In addition to the mapping tool we did not like the deployment in BizTalk. In order to deploy your process, you need to make lots of settings in different tools and places. We had hoped to find a mechanism like a WAR file for Java Web Applications in BizTalk, so that you can give one archive for your whole process solution to your administrator and he can deploy it.
We've been using BizTalk since version 2004, and now have a mix of versions 2006 R2 and 2004 running. I found that the learning curve was quite severe, and development time for solutions is not always quick. Those are definitely shortcomings. Where BizTalk really excels is in its fault tolerance, gauranteed delivery, and performance. You can rest assured that data will not get lost. Retry functionality and fault tolerance robustness is baked in so generally speaking if systems are down BizTalk will handle that and successful delivery will occur once systems come back on line. All these issues such as downtime, etc that are important in an integration scenario are handled by BizTalk.
Further, generally speaking when developing solutions BizTalk abstracts the communication protocols and data formats of the native systems by dealing with everything as xml, so when developing solutions, you typically don't have to wrote code specific to those systems, you use the BizTalk xml framework.
In the last year, we've implemented a java open source engine called Mirth for our HL7 routing. I found that for HL7 purposes, the HL7 adaptor for BizTalk is a challange to work with. Management dicated that we use Mirth for HL7 routing. Where BizTalk falls down in terms of learning curve, Mirth makes up. It is far easier to develop a solution. The problem with mirth is that it doesn't really have any gauranteed delivery. Most of the adaptors (except for hl7) have no retry functionality so if you wanted that you'd have to write your own. Second, Mirth can lose date if it goes down. I would call it very easy to use (although there is no documentation) but I'd be hard pressed to call it an enterprise solution. I'm going to check out jitterbit which was mentioned by someone else.
We used BizTalk for a couple of years, but gave it up for our own custom framework that allowed more flexibility.
There is always Sun's (now Oracle) OpenESB framework. Its generally speaking a smaller, lighter version of Biztalk but with roughly all the same features.
You do get to write more code with it, though.
Its Open Source as well.
In the OSS space (though I've never used them as a BizTalk replacement personally - this is anecdotal) you can use one of the Java/J2EE Messaging engines such as OpenMQ (which is the Sun enterprise one rebadged and without support). If you need Orchestration / Choreography (i.e. SOA/ESB pieces) on top of this, you could look into something like Apache Mule
My experience with BizTalk and doing B2B integrations is that most organizations do not truly do schema first design or fully understand xml standards for that matter. Most tend to weave objects and hope they materialize into meaninful schemas. In an enterprise environment, this is backwards.
BizTalk does have a learning curve, but once you get it you are rewarded with durability, performance, true scalability, and extensibility. Like most have said though, it best to make sure it meets your needs and contort your needs to BizTalk.
In the past I have worked with BizTalk 2004 through 2009, and another product called webMethods.
I have no direct experience with JitterBit, but I have heard very good things from coworkers.
I came across Apatar (unable to post url, but Google finds it) while looking for a solution cheaper than BizTalk. I have yet to try this out.
My last company had many problems with BizTalk being too complex and ridged, but I can’t help but think this was mainly down to the implementation the consultant did.