Data Management optimize

10+ reasons why IT pros hate Microsoft Access (but really shouldn't)

Microsoft Access may not be right for all situations, but it does have its place -- at least according to database expert Susan Harkins. Here's her take on some of the more common complaints she's encountered from IT pros who like to kick Access around.

Microsoft Access may not be right for all situations, but it does have its place -- at least according to database expert Susan Harkins. Here's her take on some of the more common complaints she's encountered from IT pros who like to kick Access around.


Until Vista came along, Access was easily the most maligned and misunderstood offering in the Microsoft Windows family. While Vista has earned its reputation, Access hasn't. It's true that Access can be a problem child, but with proper discipline, Access performs well and has its place in every organization. Still, professionals tend to spit on the floor when someone suggests Access as a possible database solution.

Note: This information is also available as a PDF download.

#1: It grew!

It's common to use Access for small, noncritical tasks even if a larger, more robust system is available. Occasionally, an Access database grows beyond its original purpose. After a year or two of use, an Access database can become vital to the organization. It doesn't happen often, but it does happen. At this point, the IT professional faces a challenge -- revamp the Access database or upgrade, and both require a lot of work.

Some IT professionals grumble... the original developer should've predicted the future and used a more sophisticated platform. That attitude is counter productive. Successful databases evolve over time. It is difficult to predict, with any certainty, the future use of a database that begins in the lower levels of an organization. Most never move up. They continue to serve their original purpose or users cast them aside.

If an Access database works its way up to the department or enterprise level, celebrate its triumph instead of trashing its creator. After all, if the database evolved and grew, your organization is growing, and that's good news for everyone.

#2: I have to support what?

Non-programmers create most Access databases. Administrators, managers, assistants, and clerks use Access to store and analyze data, without any help from IT. While the database might get the job done, it's usually inefficient and difficult to maintain. Invariably, these innovative folks end up calling IT to help resolve a bug or add a new feature. Some IT professionals simply refuse to help, and understandably so. That kind of problem-solving and debugging is difficult and time-consuming.

If the database comes from a company honcho, the IT department might have no choice but to support the database. In an effort to be proactive, some IT departments have banned Access from their organization. Unfortunately, that drastic step doesn't benefit end users. They'll use Excel, or worse, they'll call IT when they need a database. The real solution is to understand how Access fits into your organization.

#3: Access isn't a professional database

Access has the reputation of being a toy and not a real database. It's undeserved, but a lot of IT professionals simply won't use it.

Many Access developers came from a non-programming background. They found a hole and they filled it. Unfortunately, some professional programmers look down their noses at these enterprising folks, and thereby at Access. Despite the snub, Access is the most popular desktop database on the market.

#4: VBA isn't a pure language

Access uses Visual Basic for Applications (VBA) as its development language. Technically, VBA is a subset of Visual Basic (VB), so many IT pros believe Access has less value than VB. It's cockeyed thinking because one has nothing to do with the other. Professionals have many tools and they apply them efficiently, if they're smart. A subset of VB, used appropriately, is no less valuable that VB itself.

#5: It's too easy

The most ridiculous reason for avoiding Access is that it's just too easy to use -- bul...I mean, rubbish! That's exactly why the smart professional uses it. Don't hamstring your organization, support it. If Access can solve a problem quickly, use it, even if the database is just a temporary fix that frees you up to flex your robust system muscles with a real database.

#6: If you build it, something will corrupt it

Admittedly, corruption is one area where Access does drop the ball. Regardless of the source, corruption is a real problem. For some IT professionals, it's ammunition.

But the truth is, used correctly, Access rarely falls victim to corruption. Unfortunately, the majority of Access users don't always use it correctly. The debate goes on, but many IT pros simply won't support Access because of its vulnerability to corruption. To learn how to avoid Access corruption, see 10 ways to prevent Access database corruption.

#7: Money -- 'nuff said

Access applications are cheaper to build and maintain than the more sophisticated productions of SQL Server and Oracle. If the Access developer promises a $5,000 project and the SQL Server developer wants $50,000 just to get started, who's more likely to get the job? That doesn't mean that Access is the best database for the project, but the SQL Server developer must convince the client that a high-end system and ongoing support are necessary. Otherwise, Access just might rule the day.

#8: Access isn't an enterprise solution

Most organizations have different levels of responsibility. That level often determines how IT fulfills a need (or if at all). For instance, most databases have one purpose and often, just one user. The database sits on the user's system and no one else sees it, uses it, or even knows it exists. For these users, Access is a flexible and quick solution. At the top of the organization are the enterprise needs, which are more critical and require more sophisticated and powerful tools. The organization depends on these solutions and they're usually complex and expensive to develop and maintain.

No one demands that an organization use Access at the enterprise level (although I have seen it used, and expertly so, at this level). So why insist that lower levels use an enterprise database system? It's an unreasonable demand. Use the right tool for the job, no more, no less.

#9: File-server applications are inferior

Technically, Access is a file-server application and not a client-server application. That means that Access does all its processing on one server. Client-server applications process on both sides of the network. While that arrangement is more flexible, it also comes with overhead.

File-server applications aren't inferior; but they are different. Used appropriately, they're efficient and capable of outperforming client-server applications.

#10: Access is hard to deploy

Most Access applications need Access, just as an Excel spreadsheet requires Excel. That complicates deployment somewhat. First, Access is a huge application. Second, there are several versions. (I have more versions of Access than pairs of shoes in my closet!) However, if your organization uses Microsoft Office, most of your systems probably have Access installed. On the other hand, upgrades can also be a nuisance, if not outright challenging.

Still, you're going to run into these problems with any application, not just Access. In addition, if you want to maintain Access and avoid deployment issues, consider turning your databases into Web-based applications. For more on this, see 10 reasons to turn your Access applications into Web-based applications.

#11: Poor security

While most Access developers swear by its security model, the truth is, Access security simply isn't as robust as you might need. You can password-protect and even encrypt data, but Access doesn't offer the same level of security as SQL Server. (Unfortunately, the security model isn't even available in Access 2007.)

A compromised database quickly becomes a problem for IT to solve. You didn't create the mess, but you'll get to clean it up. At best, educate users not to use Access for confidential or sensitive data. (Well... you can try.)


About

Susan Sales Harkins is an IT consultant, specializing in desktop solutions. Previously, she was editor in chief for The Cobb Group, the world's largest publisher of technical journals.

82 comments
sashafroyland
sashafroyland

Microsoft Access is the world’s most widely utilized database technology ever because it’s easy to develop and delivers business value quickly which is always important and keeps programmers employed. 

The MS Access technology is sound.  The basic foundation has not changed since its release in the early 1990’s.  It’s not a sexy technology like C#, Java or .NET  but it is a solid workhorse database application technology. 

Where the breakdown occurs is here:  as the business process matures and depends more heavily on this critical business function the MS Access database performs, the flaws in the original design become exposed which is why the phase one MS Access database shouldn’t be thought of as a completed work product but rather as an evolving software solution which will need care and feeding to grow.   Think of the phase one database as a working prototype.  It’s supposed to have certain flaws because the business value hasn’t yet proven it can provide the required financial investment to support a fully compliant IT project.

Phase one Microsoft Access databases need all the nutrients that large enterprise IT projects require, which are:  business architecture, data architecture, application and technical architecture, project management and change management.  Knowing when and at what amounts to feed your phase one database application in order to nurture it into a blossoming to becoming a phase 2 database application which is a mature, more productionalized and hardened database application takes careful attention and monitoring.  Once a phase two business value has been approved, the process is to look at the phase one database architectures, develop target architectures, design a transitional architecture and roadmap, estimate the level of effort and then go back to the business with your discovery and request signoff before starting phase two development.

One instance where a MS Access database should absolutely NOT be developed in the first place is when a commercial off the shelf (COTS) or SaaS applications already exists in the market.  It’s imperative that a Buy vs. Build decision tree be followed and an exhaustive online product search for a commercial off the shelf project be performed before any coding.  However, smaller company’s (say under $10 million gross revenue),  back-office workflow processes are most often very unique and not supported by any COTS or SaaS products.  These unique processes are what give these smaller businesses their competitive advantage and phase one database application often become roadblocks for their growth when they are not nurtured appropriately.

In summary, Microsoft Access databases enable unique business processes to be solved and tremendous business value to be delivered where no commercial off the shelf (COTS) or SaaS applications exist.  Proliferation should be encouraged within these guidelines:  Buy vs. Build analysis completed, the subject matter or data is not duplicated, and lastly, database and application programming standards are adopted and implemented at appropriate amounts between phases.  Think of this as IT Asset management.

I’m trying to build a Microsoft Access database practice.  If you would like any consultancies, support or application development, please visit my site at Help4Access dot com.

Thank you.

MichaelX2012
MichaelX2012

I have used MS Access since version one. Access has evloved into an elegant indispensible platform for me. I develop Access and SQL Server applications. I use Access for data imports, quick data scenario testing, reports, exports. Access can do everything a developer wants. Access is NOT an enterprise level database and it wasn't meant to be. Anyone who points out the flaws of Access and those flaws are enterprise database related are not getting the point. I have used Access in situations that saved a company hundreds of thousands of dollars. The real and most important consideration of ANY application is "Does it work? Can it perform the way it was deisgned to perform?" The answer for Access is "Yes!". For all of the naysayers out there... you all truly do NOT know what you are missing. In this competitve development world, Access is a powerful tool in my arsenal. My question for the naysayers is this: "Have you actually used or even tried to use Access to resolve a problem?" If you answer is "No" then that is probably why you feel the way you do. Access, just like any other devlopment tool, must be properly used. When properly used Access is the best in it's class.

PatHartman
PatHartman

I am disappointed in this article and others by Susan because she has had many opportunities to clear the mud from the waters and hasn?t taken advantage. Comparing Access and SQL server is simply meaningless. SQL server simply doesn?t provide any way to create a user interface so I don?t know why people keep trying to compare the two and Access is not a database engine!!! It is a tool for creating a user interface. Jet IS a database engine. Yes, it is true, the Access application is ultimately stored in a Jet database but what has that got to do with the price of tea in China? VB.net code can be stored as plain text files. Does that mean that you should compare notepad to visual studio because they can both be used to edit the code? Access is a development environment and supports VBA as its embedded language. Jet (or ACE) is a database engine. They are NOT the same!!!! Comparing Access to SQL Server is like comparing Excel to Word because they both let you create table like data structures. A semi-valid comparison is Jet to SQL Server or Oracle since both are database engines. However even that comparison is weak because Jet is a file server and SQL Server and Oracle are database servers and they operate differently and provide different functionality. If you want to compare Access to something, compare it to Visual Studio with VB.Net or compare it to Oracle Forms. All the drawbacks mentioned in this article are limitations of Jet/ACE, NOT limitations of Access. Please, Susan, make an effort to clear up this confusion rather than contributing to it. If you can make IT folks understand the two tools and the fact that Access is in no way tied to Jet/ACE (except as a container to hold Access objects) or even to SQL Server, perhaps Access will be able to gain its rightful place in the toolboxes of developers everywhere. I?ve created hundreds of Access applications over the past 15 years and fewer than 20% actually use Jet/ACE as their data repository. The rest use SQL Server, Oracle, DB2, Sybase, Pervasive, MySQL, and more. Some use multiple back end databases. Please ? stop the madness. Access IS NOT Jet!!!!

juddly
juddly

When Access tries to overwrite my own SQL and gives back an error on it's own changes, there is something wrong. Then it won't even let me open the SQL to fix the problem. Ever had an error "Invalid Bracketing" on a simple subquery? It should allow me to disable this auto-coder or error to check the SQL. Now I'm stuck with query objects that work fine but can't be edited. Garbage!

RayJeff
RayJeff

I've asked this question over the years on several other sites as it relates to developing user interface applications with Access. The typical response has been that it comes down to personal preference. When I started the developing the user interface for the Access database I created, I went with VB6 for many reasons. One, was I had no experience using VB.NET. Two, was that I was already much more familiar with VB6, so the learning curve wasn't there. Three and most importantly, I had no experience with VBA. And while I'm sure the learning curve would not have been an issue, time constraints with the project I was working on didn't allow me the time to learn VBA. It's interesting that one of the database specialists I consulted with on the development of my database developed the user interface application for the database at her institution using VBA. It was apparent the specialist has much experience with VBA. But, when I asked about the same or similar parts of her application to mine and to transpose them, well, I couldn't get any help because she had no experience with VB. So, I would say from my view, using VB or VBA with Access depends on several factors, with the main factor depending on comprehensive the application will be. Not to say that a VBA application cannot be very comprehensive, because I was in awe while reviewing the database specialists applications using VBA. But, when you enter the limitations VBA has, it comes down again to personal choice.

RayJeff
RayJeff

I haven't read the comments yet, but I had to get my experience out with Access. I was hired to work for the Education division of a small liberal arts college in 2003. My main duties were to provide help desk/end-user support of the division, students, other faculty and run a computer lab. What I didn't know at the time of being interviewed that the Teacher Education program was goign through a national accreditation. One of the parts of the accreditation is that the program information had to be transferred to an electronic storage system-basically all information has to go from paper to a database. Now, during my interviews for the job, my former supervisor mentioned offhandedly about needing to have a database to store student data. Within the time of my last interview until I was hired, I came up with a quick template based on the little bit of information I got. While my IT experience was basically in tech support, in my last job before it, I created log tracking "databases" Excel and I messed around with creating a small Access database to store the combined data from the Excel spreadsheets. But, what help me out was I was in school at the same time and I had just finished a 2 class sequence in Java. So, my mindset was already in programmer/developer mode I had to use Access for many reasons. What I didn't know about the accreditation process at the time is that it's 5 year process. I got hired at the end of year 3; SO, I had alot of catching up to do. There was no kind of documentation in place or available. Because I worked in a division of non-technical people, they didn't know what to do. They knew that they needed a database, but didn't know how to even begin to setup requirements for the database, much less the actual information going into it. So, the role of programmer was the last thing; so, I truly became a developer. With all of these things, Access was the only system I could use in the time I had left to develop and use. Oh, did I forgot to say I had to develop a user interface at the same time for the faculty to use, eventually down the line. And one last thing; I had no one to work with me on this. I did all the work myself. There was no group of developers/programmers/database people to work with me or assist me. I did correspond with and visited with database specialists at other schools who had gone through the accreditation process, so that helped me greatly. What also made Access perfect was because actual information going in. The students going into the Teacher Education Unit (program) each year is very small. Students are tracked from the moment they declare Teacher Education a s a major until they have graduated with their degree and are actually teaching. Now, while in college, the actual number of students declines from the time students declare the major for whatever reasons ( changing majors or into enrolled at the college). So, Access is perfect for that as far as the small number of students entered into the database. But, the eventual problem is the exponential rise of information for each student. So in that case, a database system to accommodate that was necessary in the near future. And if i was still at the college, I would've made the move to SQL Server. Well, to make a very long story short, was the accreditation process, with all of its issues went great and the program got accredited. And one of the main reasons why because was able to get a database setup up and running, because the database had to be reviewed by the accreditation body. Don't get me wrong, I made many mistakes, but they were the mistakes of a person who was a first time database developer, and I have long learned my lessons.

gordon
gordon

Reason #1^H 0: It uses VBA. Let's say you need to check the date of a file before importing it. You use FileDateTime(path). Now, if the file does not exist, it throws an exception. OK, you say; I'll test for FileExists(path). Wrong! There is no FileExists function in VBA. Let's say you want to use a hash to hold key,value pairs, so that you can address things like col = hash("name"). VBA has a crippled, brain-dead implementation called a collection. You can write hash.add "name",3. But if "name" already exist, it throws an exception. Think you can check if hash("name") exists? WRONG! See #1 above. Let me remind you that this is Version 6.5 of VBA. 6.5 Major Versions and they haven't figured out that people need to check if things exist in a language that throws up when they don't??? #1 VBA error messages Have nothing to do with the actual error. #2 Microsoft SQL: Will NOT tell you where in your long SQL command it gets lost. It knows. It just won't tell you. #3 Microsoft Help Let's say you want to do something you *know* is in Access or VBA, but can't remember it's name. For example, let's create a constant. Open the VBA help, go to the index and type "constant". No help found. OK, type "constants". Still no help. Now type "const". Bingo! You found it. Of course, if you knew what it was you wouldn't be looking in the help! And what kind of help can't find the plurals or singulars of common words? Does MS think that if I ask for help on "loops" I'm not interested in the loop statement? ARRRRGH!!!! Access and VBA are crimes for which Microsoft should be prosecuted.

roaming
roaming

What happens if it is stored on the local drive which has just died and they want it restored? As far as cost being a concern what about PostgreSQL and MySQL?

ferreirah@webmail.co.za
ferreirah@webmail.co.za

With Access 2007 you can deploy the runtime engine without having to buy Access. Also, this is now my second job where we are using SQL Server as a backend and Access as a front end. You get the stability of a client/server database with the ease of use of front end development. If you can't afford SQL Server use SQL Server Express or MySQL or Postgres. We got databases on SQL Server as well as AS400 which we manage thru Access. I dont think Access 2007 got multi user features but you can combine it with a client server database.

Tink!
Tink!

Personally I like Access. But that's because I've always worked in smaller companies where the user base and deployment is very small. Because of this I am able to customize the Access Database to meet the required needs exactly. I've created several Access databases now that have been used exclusively within the companies I work(ed) for. Including 1 for taking messages at reception, 1 for keeping track of a bridal registry and am currently using 1 for tracking inventory with barcodes, and for tracking raw material costs. For larger applications and companies I can understand not wanting to use Access. It's a rather primitive and cumbersome application compared to other softwares. But for the smaller instances, I think it fits just fine.

djnewman
djnewman

I support and develop in MSAccess daily. When Access is used properly it can be a very robust solution and TCO can be very low compared to SQL Server or Oracle for the right projects. Things to consider: 1) MS Access is the front end application layer. It can connect to any number of databases from many vendors, SQL server, Oracle, DB2 etc. Pretty much anything that can use ODBC can be used with Access. I dare you to come up with a reporting solution that is as easy to work with as Access and can create as complex a report in as short a development time frame. Crystal Reports is no where near as capable, and even SQL reporting services is not there yet. With the added benefit of stored queries and VBA, it's a solution that should be considered for any Non Enterprise problem. 2) Jet databases are separate from Access and can be used with many other front ends such as Visual Basic, ASP, and even .NET. Jet databases are fine as long as you don't cross network boundries and you can live with minimal security. For example, they make great local databases for storing program components like queries and reports. Put the data in a secure place like SQL server where it belongs. If you step outside of these boundries, you are asking for trouble. Finally, any company that lets the secretarial staff create databases for any purpose is asking for trouble.

jmgarvin
jmgarvin

It's a nightmare to deal with. It's got too many issues with security and with scaling. The biggest problem is that the users can do things (like delete a db) when they shouldn't be able to. There is no reason to use access unless you want to federate all your data.

50-50
50-50

In my former life I supported end-user computing, both user-developed database applications and end-user reporting from enterprise application data. Now I'm a DBA, looking at database applications from the other side. The biggest problem with MS-Access from my current point of view is the lousy way it behaves when using ODBC or OLE to connect to a remote database. Access has a bad habit of turning the remote database into a single-user-at-a-time resource. It isn't very smart when generating SQL. It often prefers to do operations locally that would be better done inside the remote RDBMS. However, because it comes "free" with Office-Pro in many companies' standard PC image while real report writers cost real money, it becomes the default solution for creating "simple end-user reports" even though it's not a good report writer and many end-user reports are anything but simple.

blarman
blarman

#1. Growth. The problem with this mentality is that you have someone who develops an application using Access that did it without other approval (especially input from IT). This bespeaks an internal management/controls issue much more than an IT issue. #2. See #1 above. The issue here is the company's approved internal development policy. #3. It isn't. Get over it. Access is for SMALL workgroups with a VERY low number of concurrent transactions (2/second) and for databases

Jimmy Lin
Jimmy Lin

I think the main misunderstanding about access is that it is not a server applicaion, but a desktop application. It is not designed for multiple people to run it from a server at the same time which is the cause of the corruption problem. The solution we found was to detach the access front-end from the access back-end, upconvert the access backend to SQL Server, and attach the access front-end to the SQL Server back-end via ODBC. We put a copy of the access front-end on each desktop and in doing so have never had a corrupted front-end since and we have been doing this for about 6 years now. This raises the issue of making changes to the access front-end since everybody has their own copy. We chose to use the microsoft installer from visual studio to create an install package for our users to update their computers whenever we make changes to the front-end. You just have to remember that any queries created by users in their own copy of the front-end are lost unless you first import them into the new front-end before creating the install package.

John Dickey
John Dickey

Having been around and used Access since the beginning I have experienced all of the good and bad of it. For myself Access provided and still does today an easy to use tool for RAD and proof of concept at relatively low cost. I have used Access in front end back end combination since the beginning and more recently through my consulting have seen increasing requests to turn applications that companies have developed (Note: most are 50 or less employees with usually 5 to 10 users with revenues of 20M US or less) into web based applications. For the majority of these small businesses the move makes sense. However, when I see that the demand will increase or what they are presently using the database for makes them liable to HIPPA or SOX, I take the time to educate the clients and move them to a SQL Express or MS SQL backend. As to specific points... #1 it grew... true it happens, but on the other hand most organizations that I have worked with would never have commited the resources to a costlier soulution from the get go. #3 ...not professional ... well I once worked for a company where one of the owners though that... but then again he felt foxpro 2.1 was the end all be all too... when I showed him how Access could be used to address dedicated solutions in minimal time he changed his tune #11 poor security ... that one I have to agree with especially in view of the fact that the security model is not even a part of 2007. In light of the very real issues today of data theft and privacy Access should never be used in those situations. All of the above being said, I personally believe Access today still has a position to fill in an organization. The key is to evaluate what it is being used for and why the business model prevents a different solution from being used.

ChrisHyche@AlabamaOne.Org
ChrisHyche@AlabamaOne.Org

...it requires write access to the location it is stored! I can't tell you how many time users had "accidentally" moved or deleted a common use Access database at my last place. Fortunately at the time we had Netware with the excellent Salvage command(pre-shadow copy).

Underground_In_TN
Underground_In_TN

Loading business data from all the various Access databases that build up over time gets tricky, usually takes a lot of time and dollars to develop and are often overlooked simply because only a few people know about them. That negates #7 above, as actual ROI begins to shrink from what it first appeared to be with that $5000 initial develop cost.

marie-noelle.baechler
marie-noelle.baechler

I have seen quite a few cases where the sum of all user needs is far greater than what the IT department can do with its budget (and people). So, there are many cases where the developpment of applications by users is unavoidable. But it seems to me that proposing appropriate solutions for these developpments is extremely important if IT deparmtments want to avoid to face emergencies, when one of these developpment fails or when a critical user leaves. Another important point is that the fact that an application is used by a very small group (less than 10 people) does not necessarily mean that this application (and the corresponding datas) are not critical for the whole company (administration, NGO, ...). I used Access in similar situations in the past and I saw several very important drawbacks. some of the most important were corrupt databases and failures to migrate access applications from one version of access to another one. It is not very complicated to create an instance of an enterprise databases (with your preferred RDBMS) dedicated to the storage of tables and datas of end user developpments. Thus, user datas will at least be stored and managed according to the guidelines of the company. In addition, the IT department will have an easier job if an optimization or a repair is needed. It will also make easier to handle problems related with data integration, concurrent access, security and so on. But it leaves the "user knowledge" on the desktop in a fragile container. I have obviously no miracle solution to this problem. I just notice that there are alternatives to access (for example ORACLE Application express, FileMaker, 4D, and so on), which can also be used with a remote database. It may make sense to examine these alternatives in order to see wether one of them would be more appropriate for the needs of a given company. Introducing it may be easier if the IT department is able to give some support for applications developped with it.

CharlieSpencer
CharlieSpencer

I've seen this a few times. Someone thinks they need to manage some related data and uses Access to create a database. They require others to enter data, occasionally going to the effort to create entry forms. After a couple of years this person leaves. Sometimes his replacement will ask for changes to the database or forms, requiring IT to allocate resources. More frequently the replacement has no use for the data at all, and those formerly required to enter the data start popping the champagne corks.

PatHartman
PatHartman

Access with VBA is designed specifically to create data centric applications. It doesn't have the language features needed to effectively create a 3-d animated game. I don't think that makes VBA inferior. Access/VBA is an extremely optimized tool for creating business applications that involve managing relatonal databases. VB is a much more generic tool and lacks the features necessary to create the same applications quickly so from my perspective, VB is the inferior tool:) The ultimate power of Access is the way it handles ODBC data. I have a database that is sold to the public. Some clients want their data to be held in SQL Server and others want to use Jet/ACE. All that is required to support this is to delete the links to one set of tables and link to a set from a different source. You can't get any more flexibile or scalable than that. VB and VBA differ in the object models they support. VBA is an embedded language and is customized for each product. Therefore VBA for Word is slightly different from VBA for Excel which is slightly different from VBA for Access. However, if you are familiar with any VB or VBA implementation, all you need to understand another one is an understanding of the specific object model.

kallal
kallal

You are kind of confusing the issue here a little bit because you can?t use VB6 with ms-access. You can certainly use vb6 with the jet database engine, but that?s completely different product then MS access is. I should point out that MS access actually shares the same compiler with visual basic 6, and they actually share the same code base. There is virtually little if any differences in syntax between VB6 and VBA. As I said, they are in fact are the same product, the only difference between developing with VBA in ms-access as opposed to vb6 is you are dealing with different object models when it comes to things like forms. So the language is the same in both cases, it?s only the object models you are dealing with that are changed. So the learning curve is not tied to the actual language itself when you go from VBA to VB6. If you?ve learned one language (vb6), then you know VBA (and vice versa). About the only difference between the two is vb6 had a native compile option where as VBA is still restricted to compiling to p-code. Albert D. Kallal (access mvp) Edmonton, Alberta Canada kallal@msn.com

ssharkins
ssharkins

First, VBA is a subset of VB. That means that VBA isn't as robust as VB. However, most anything you create using VBA should readily transfer to VB. Second, VBA is restricted to the Access environment, whereas VB isn't. What that means is, you'll use VBA inside Access to manipulate and automate Access objects and data. You'll use VB to control Access data from outside the mdb file proper. Hope that makes sense.

kallal
kallal

I worked with just about every language for the last 20 years, from assumber, c++, Pascal, and everything in-between. You need to learn the language you are using, and only a fool blames the tools, not their own lack of ability. Let take a few here: >Reason #1^H 0: It uses VBA. Let's say you need to check the date of a file before importing it. You use FileDateTime(path). Now, if the file does not exist, it throws an exception. OK, you say; I'll test for FileExists(path). Wrong! There is no FileExists function in VBA. You use the ?dir? command in place of it you silly! Eg: If dir(strFilename) ?? then dtDate = FileDateTime(strFilName) end if Now, was that really too hard? How lame can you get here!! >You can write hash.add "name",3. But if "name" already exist, it throws an exception. Think you can check if hash("name") exists? WRONG! See #1 above. Well, first, you do have a database engine why not use that? However, the collections we have are the same as vb6 did (.net obviously gives you better choices in the types of collections). However, what is the problem with the following code: On Error Resume Next strV = myCollection("joe") If Err.Number 0 Then MsgBox "joe not in collection" Else MsgBox "joe in collection" End If It is really simple solution to find ?joe? in the collection. Once again you obviously not learned the language so you blame it. These are trivial beginner questions and answers. The solutions I posted are really simple and don't involve some "trick". >For example, let's create a constant. Open the VBA help, go to the index and type "constant". No help found. OK, type "constants". Both a2003, and 2007 gave me ample hits for typing in constant in the help. Perhaps you have a older version, and the help files for 2000 were a mess, but for 2003, and 2007, they are quite nice and both returned fine results by typing in constant, or constants. Just make sure you do the search from the IDE side, as help is ?split? between end users (non programmers ? help from access forms/reports side as opposed to using help from the IDE - developer side). Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com

iseymour
iseymour

I think the article is entirely fair. I have successfully developed solutions using Access in small environments, < 30 users, ever since Access 2. I have not experienced a corruption issue since upgrading to Access 2000 years ago and when one application began to grow in size moving the back end to SQL Server couldnt have been much more straight forward. As for most of the access criticisms, apart from non existant security, I think they normally demonstrate lack of knowledge of the current product or what it is designed to do: It's not client server, well no who said it was. There aren't database administrator tools, well no, not many departments, small organisations can afford such a person. A non IT person who doesnt know what they are doing might get in a mess. Well I would guess occassionally an IT person who claims to know what they are doing gets in a mess with SQL server, mySQL etc. Non IT peeople dont do things the right way. I do love the implication that there is a right way in the first place, post a real life database problem here I bet you get a different solution from everyone that replies and an argument over which answers best. Finally, as I said I am used to a small environment which I am sure makes a difference but if I found some one had created a mission critical application without wanting or feeling able to ask me for help then I would have a lot more to worry about than whether they declared their variables properly.

Tony Hopkinson
Tony Hopkinson

for me. What happens to the wider business if it fails and there no IT awareness or involvement, is the real point. It can be a perfectly suitable tool in or outside of IT's remit, it can also be a wholly unsuitable one. Someone who knows their way around the IT of the business should assess that. We've all been forced to a less than optimal solution on occasion, it's ignorance of the consequences of that decision that's the problem. A significant loss of business functionality, because someone's personal computer suffered a mischief for instance can't be acceptable.

Jimmy Lin
Jimmy Lin

I have seen the single-user-at-a-time before. The database was accidently configured with table level locking instead of row level locking. I agree that access does a lot of things that should be done at the server end that causes response time issues, but because of the extra tools access gives the users, they are able to do more and have to come to me for help less often.

del_star_dot_star
del_star_dot_star

#9. If you are doing a lot of network queries to a central DB, Access quickly becomes a poor choice. Access is anything but efficient in terms of bandwidth. If you are using Access, copying the database to your local PC and running the queries locally is a much better choice - unless you don't mind a terminally slow network. Been there, done that, and it ain't pretty." I had been banging my head against the wall for months when it came to generating the monthly/ytd reports (lots of iterations in the VBA code) over the network share. It was taking minutes to make a single report over the network and the traffic was around 5Mb. The problem was compounded by Sophos AV. The Admin has it set to download updates hourly, and has on-access scanning running full-time. I was using an Autohotkey script to do as you've suggested, copying the db and running it locally. I also tried importing tables into the front end, but that took too long, and running the reports from linked tables wasn't much better. I found that creating both internal tables and linked tables, flushing the internal ones and refreshing them with queries on the linked tables yielded a significant performance increase and will allow for the hands-free operation I'm developing. I've tried to get the IT department to install SQL Server or similar back-end, with no luck. In the meantime, the workaround is functioning quite well for the needs of the company. Access does have annoying limitations, but many of them can be worked around or outright resolved by thinking outside the textbook.

timjgreen2
timjgreen2

"#1. Growth. The problem with this mentality is that you have someone who develops an application using Access that did it without other approval (especially input from IT). This bespeaks an internal management/controls issue much more than an IT issue." I'm an accountant, so don't think that internal control isn't important to me, but some IT people just can't get their heads around the fact that they exist to support users, not to control them and limit them. If you used the argument above to a senior manager, they would be very worried that IT have no understanding of business needs, and think their narrow objectives and defending their patch are more important than achieving the company's mission. Any app that empowers users is likely to be hated by internal IT, and loved by external consultants. If you don't believe me, read any of the posts in this thread. And can I finally add that an enthusiastic IT amateur can mess up the data just as easily in Excel as they can in Access, but nobody suggests banning the use of Excel. This proves that the real motive for the hatred of Access and its users is down to marking territory rather than a genuine concern for the enterprise's data.

PJL1941
PJL1941

Without access most organisations would not even have a data base and would not even know about SQL.

Tony Hopkinson
Tony Hopkinson

Seen that a lot. The people doing the work get nothing out of it. Access or another tool used to sidestep the requirement for a business case.

RayJeff
RayJeff

>>>>?I should point out that MS access actually shares the same compiler with visual basic 6, and they actually share the same code base. There is virtually little if any differences in syntax between VB6 and VBA. As I said, they are in fact are the same product, the only difference between developing with VBA in ms-access as opposed to vb6 is you are dealing with different object models when it comes to things like forms. ? But, there must be a significant difference in the syntax when the database specialist I consulted couldn?t help we with a possible conversion of some of the VBA coding to a VB equivalent? >>>>"So the learning curve is not tied to the actual language itself when you go from VBA to VB6. If you?ve learned one language (vb6), then you know VBA (and vice versa)." But, wouldn?t the learning curve make a difference as far as the language, depending on how complex the application will be?

gordon
gordon

RE >Reason #1^H 0: Guy: Lacks simple functions like FileExists. Albert: You use the ?dir? command in place of it you silly! Oh, thanks very much. Like I didn't know that. I guess the point totally flew over your head. Yes, there's a work-around for every problem I can list for this pitiful excuse of a language. Why should the programmer *have* to work around it? Do you think you'll find that (or any) work-around in the help under "File Exists"? Do you think code doing a Dir and checking for the filename (which is returned as the default property, and thus not mentioned in the code) is more clear? Is it self-documenting? Which took longer to write? What if MS decides the return "File not found." in VBA v7.0??? Al: "you do have a database engine why not use that?" Guy: Well, maybe because you don't want the overhead? (I guess only bad programmers worry about performance, too.) Al: "what is the problem with...On Error Resume Next..." You've got to be kidding, right? You're asking what's the problem with catching ALL errors and assuming it's the answer you wanted? You don't see anything wrong with using Error Exception Handling to do flow control? You never have to maintain your own code, do you? Al: "These are trivial beginner questions and answers." Guy: They weren't "questions" Al. They're examples. I didn't ask how to do them. I asked why a language in version 6.5 doesn't have such simple functions. Why doesn't VBA have collection.exists(object)? Why did you have to write seven lines of code to accomplish that? You write as if you're under the impression that all languages are equally good -- blame the programmers. This is the attitude of a beginner who only knows one language. I suggest you learn a few more and get experience in each of them. Especially in maintaining each of them.

Tony Hopkinson
Tony Hopkinson

On Error Resume Next. If Err.Number 0 There's two things for starters. VB6 was designed so numpties could write applications, it was far too successful at that.

ssharkins
ssharkins

Thank you for your intelligent and thoughtful responses.

ssharkins
ssharkins

That's a nice response -- thank you.

Tink!
Tink!

That was rather poetic - in a techie kind of way. And I agree with what you say. :)

Tony Hopkinson
Tony Hopkinson

No that is worse. I know from bitter experience. IT does not exist to support users, it exists to support the business. IT is not allowing you access to a web site, or cleaning the ball in your mouse. It's the management of information with technology. So if can you put something together on your PC to help you do your job, we've done ours. If you put something together on your PC to help others do their job, your computer is no longer personal. This is a very important distinction. All any professional with responsibility to a business' IT function asks is. That you let them know of the change of status. That you seek their advice on what that means. That if for pragmatic reasons you choose not to address the change in status of your PC, that you (and the business) understand the consequences. That you don't get all bent out of shape, if it goes nipples up and we weren't aware of what you were doing. Not hard, and good for you, us and the business, which is the point is it not? Whether you use access, excel, or SQL Server and Visual Studio express and are a .NET 3.5 client server database genius, is irrelevant. What matters, is if we don't know it's there it will not be supported properly.

marie-noelle.baechler
marie-noelle.baechler

In many places where I have been, IT people are deeply aware that they exist to support users. Yet, there are cases where fulfilling this mission means limiting them. One of the mission of IT people is to make sure that the information system of the whole company is always usable, i.e. that there is no risk of loss of critical datas nor of critial user knowledge. There are cases where this mission takes precedence over the initiatives of smaller groups. They are also paid for this. Even the senoir managers (who gave them this mission and who gave them their priorities) will support them, when some action may endanger this mission. Most users who make Access or Excel developpment have very legimtiate motivations. Yet, they do not understand that they use very fragile tools (for all the reasons mentionned in this discussion) and they do not understand the consquences for the whole information system of their actions beyond their immediate (and legitimate) need. Internal IT have no reason to hate applications that enpower users. To the contrary, they help them a lot focusing on their core missions. It is also not a question of "defending a patch". But I have seen cases where people spontaneously placed absolutely vital informations in access databases (built by themselves) and asked for help later when their database were corrputed beyond repair. Consequences were very painful and not only for them. Giving the proper tools to users is very important for all actors (users, compagnies and the IT). The problem with access (at least alone) is its fragility and lack of reliability. All the solutions mentionned in this discussions are centered around the ways to reduce this risk (or alternative solutions).

ssharkins
ssharkins

I don't want to harass IT personnel, and I think the article is pretty neutral in that regard. But one reason unskilled people turn to Access is because they can't get what they need from IT and there's nothing in the budget for hiring a consultant/developer -- yet, they still have the responsibility for collecting data for some reason. Many of the development projects I've gotten were from companies with IT departments who couldn't handle the request for a database. My personal experience with IT spanned a single company over 5 years. During that time, I never sat in on a meeting with IT where they said yes to a single thing -- their response was always, "No, we can't do that..." -- always. I can't judge that response however. I will say that if a company expects IT to consult and develop, they need to support that decision financially with training and personnel. I think that people outside of IT see the department as all encompassing. I think the folks inside IT don't. Many companies are still very uncomfortable defining IT's purpose within their own organization and thereby, let IT do it by default.

RayJeff
RayJeff

"No question at the end of the day that an experienced access developer is going to do a far better job of making that vb6 code run because they understand the application object model. So while there?s no learning curve in the syntax of the language, there?s most certainly is a significant learning curve in using the access application object model." Gotcha....

kallal
kallal

I would question what that person?s a specialist in. Just because a person knows oracle or SQL server and is a databae specialist, what does that have to do with a programming language like VBA or vb6? If the person could not help you convert that the VB6 example code to VBA then that person simply was not experienced in using those languages, end of story. I?m going to repeat this again: The syntax of both languages is exactly the same, the only differences is that ones is dealing with an different object models. Again same syntax. I took a vb6 Internet transfer library example that uses the windows API + the wininet.dll?s written for vb6 and the code ran perfectly well under VBA in access. There was a few minor tweaks and changes because of the way access exposes the application hwnd handles, but the language syntax is still the same in both vba or vb6. What this means is now that I have a full Internet transfer library now natively available inside of my access applications that can transfer data to and from web sites. > wouldn?t the learning curve make a difference as far as the language, depending on how complex the application will be? The language is the same, but the objects you dealing with are different. You?re likely confusing the difference between an applications object model, and that of the syntax of the programming language itself. They?re the same language and anybody who?s experienced in MS access VBA should be able to take that the vb6 code and with minor changes to objects referenced will allow that code to run under VBA. No question at the end of the day that an experienced access developer is going to do a far better job of making that vb6 code run because they understand the application object model. So while there?s no learning curve in the syntax of the language, there?s most certainly is a significant learning curve in using the access application object model. Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com

Tony Hopkinson
Tony Hopkinson

You and I (and many others) find it very easy to separate the access database engine from the front end. Access however is aimed at those who do not even understand that distinction. You and I (and many others) know that VBA has some severe limitations, they exist precisely to make the language approachable to those who do not. Most 'professionals' distaste for access comes not from what it can and can't do, but from attempting to cope with the messes the these amateurs have already created with it. It's not that access is an amateur tool, it's that it is in the main, it's designed to be the tool for the amateur. Guilt by association, basically....

kallal
kallal

>It's not too difficult, even for a relative beginner, to code some custom error-handling. for sure we all agree with this.. Actually, this issue of error handling is a legitimate gripe here. The point being made here is not that a developer needs to incorporate error handling, but in fact that some things REALLY should not be considered an error. For example, opening a text file with legacy code (as opposed to using the fso object) will cause an trappable error in vba if the file does not exist. Well, in my books having to trap an error to find out the file don?t exist is not very pretty (but, one can/should use the dir()to solve this problem). When you load up a reocrdset with some sql, if the id or name you searched for does not exists you don?t get a error (you get reocrdCount = 0, or noMatch = true). So, that is the point being made here. And, while I was quite hard on the poster about how easy the workarounds to his collection objects are, the fact that we must resort to error handling code to check for a member of a collection is missing is a true and fair criticism of VBA. When one has spent some time in .net, then try/catch syntax is a far better error handling approach. While both .net and vba do cause a trappable error when a member of the collection does not exists, you can in .net use contains and not resort to error code. After using .net going back to vba one does find the error handling somewhat messy. So, I just hate those goto?s and it makes code hard to read and hard to maintain. However, thus I offered the poster a NICE workaround in which we don?t use on-error goto, but use resume next (and, as mentioned, one would check err = some number not just use 0). Anyway, this approach gives a VERY similar program flow to error handling in .net, and you don?t have code flow that ?jumps? to places when an error occurs. So, while the other poster was complaining about learning and using other languages, in fact my experience with other languages is exactly why I offered up a nice solution that gives a if?then block of code to solve his problem and NOT code with a goto that jumps all over the place. So, with a bit of experience and using my suggestions then error handling does the job just fine vba. I always welcome discussions about a product, and I don?t mind criticisms of access. However, it seems that several of the posters are simply of the nature that ms-access is not a serious development tool and some how using c++ makes the person cool and somehow more professional. (it does not!!). And, if you use ms-access you are a wossy. Too many people are so eager to crap on ms-access. Access is a fabulous tool for developing data centric applications. Access still runs circles around .net in terms of speed of development of data applications. As long as you stay within the constraints of the product, it is a winner. As for scalability once again most of the posters here are just dead wrong, and using the correct database engine with access such as the free sql server means that 30-50 users will not even make the application sweat in terms of performance. And, the free edition of slq server works great with ms-access. (so many posters here talked about using sql server..but fail to mention how you build forms in sql server? Geesh guys, at least learn difference between a development tool like ms-access and a database engine like sql server or jet. They are complete different tools, but it been just a hoot to see how silly some of the posts here are). Now that the runtime system is a free download, users of your application don?t have to purchase ms-access anymore. So, you can build client/server applications and deploy them for free to any computer. It is a great tool in the hands of great devleoper, and a bad one in terms of a bad devleoper. And, beleive me...the applications I seen written in c++ or vb6 tend to be FAR worse then the ones written in access (really!!). Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com

Tony Hopkinson
Tony Hopkinson

it trivialises it. ON ERROR RESUME NEXT or worse still GOTO is a language limitation not a strength. Yes a competent developer in language X can work around such constraints, but those constraints weren't put in for laugh. VBA/VB6 has no Exception support worth talking about. Excpetions weren't invented to make them look stupid, but because they are better than optionally checking a return value. You can use an adjustable wrench to take off your cylinder head, don't be too surprised if you round the nuts off though. Be even less surprised when after continued use, someone says "round, huh"

del_star_dot_star
del_star_dot_star

"Al: "what is the problem with...On Error Resume Next..." You've got to be kidding, right? You're asking what's the problem with catching ALL errors and assuming it's the answer you wanted? You don't see anything wrong with using Error Exception Handling to do flow control? You never have to maintain your own code, do you?" It's not too difficult, even for a relative beginner, to code some custom error-handling. I do agree with you about the help files, though. It can often be difficult to return the relevant search results. I also agree about the file manipulation functions. They tend to be clunky at best, and sometimes I'd rather use API for them rather than native VBA code. I remember there being a FileExists, or similar, in Excel VBA, but it didn't work properly on my development machine.

kallal
kallal

>Yes, there's a work-around for every problem The question is HOW big of a work around. If you going to nit-pick, at least make your case here. That was my only point. >Do you think you'll find that (or any) work-around in the help under "File Exists"? What are you criticizing here? You think you have a fileExists in c++ also? You simply have to use the resources and community information at hand to solve your solution (hint: that is what software developers do). The fact is that the you simply use dir() in place of fileexist() and I stand by that this is a trivial matter. We are not talking about using a windows api or some such here. You are trying to make a mountain out of this, and that why I responded. Throw your criticisms freely. Hit hard! But, at least try make them legitimate ones. And, no, I don?t know of ?IDE?s? that offer workarounds. Dir() is how you do this in access and it not any less code then if we had a fileExists. The my language is better then your favorate language debate was exciting in grade school for about 5 minutes here. I not trying to say vba is that great language. >Al: "what is the problem with...On Error Resume Next..." You've got to be kidding, right? You're asking what's the problem with catching ALL errors Take a pill here. It was air code, you can code to the specific error if you want and one would define constants for that purpose (thus you get err = mcolNotInCollection in place of a .net exception). Thus you would NOT be trapping all errors. And furthermore, we not using on error goto to ?jump? program flow, we using a if..then block, something you obviously missed here. >You don't see anything wrong with using Error Exception Handling to do flow control? You have to explain to how this is diffent or worse then using exceptions (catch/try) in .net? So using an exception (error handling) in .net is ok, but in but in VBA it is not? In both platforms, feeding a collection a wrong value will cause an exception/error. Or are you here to tell me that .net is also not to your liking either? I be fair here and note that you can accomplish this in .net without using a catch/try, but the program flow in both cases is going to be a if/then block of code. So, why is this a problem? Even after you do a contains in .net you have to write the code to grab and deal with the value. So, you going to wind up writing about the same number of lines of code in both cases. (you need test for existence + if/then block of code in .net, or err = mcolNotInCollection + else block of code in vba). As I said, the data likely is coming form a table so the need to use a collection is VERY rare anyway. >Why doesn't VBA have collection.exists(object)? Why did you have to write seven lines of code to accomplish that? Again you are being hysterical here. It is 2 lines of code. If you did have .exists() property of the collection object then you would still have to write the if/then program flow block as I had. Again, please be reasonable with your criticizing, it is not even close to 7 lines of code. If this is such a big deal, then in vba (or even .net) you would simply spend 3 minutes of your time and write your own class collection object. By the way you can create class objects in access (assuming you know what they are?). Once you do this, then you will have your collection object with your .Exists() property and can use it for the next 10 years. This is a trivial problem solved by any developer working in VBA, or .net for these types of problems. That is what developers do. So we don?t need collections very often. So you can use resume next in place on error goto?s to get a if/then block and similar code to try/catch. So you can spend 3 minutes writing your own collection object if you really need such ability All of the above points to this NOT being a big deal. >I suggest you learn a few more and get experience in each of them. I suggest you learn what it takes to be a developer. Your fileExits() complaint is lame and is the result of lack of knowledge. And your collection complaint is lame also. A trivial matter with a trivial solution. Both collections in vba and .net throw an error for passed wrong values anyway! Generally, in both cases, you are VERY likely to create your OWN collection object based on an internal collection type (well, ok in vba, we only have ONE type of collection, in .net you have several types). Anyway, this means a few extra lines of code in a new class that you create, but this only need be done ONCE for your whole project. If you are suggesting that it is a great idea to have a .Exists() for collections, then fine, I am 100% with you and 100% agree with you. However using the err object in vba makes this issue trivial and it not a huge workaround deal. To me, shortcomings in a language/system are not things that can be fixed by a junior developer in less time then it takes me to write this post, and your examples fall into this easy to fix category. Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com

Tony Hopkinson
Tony Hopkinson

The best way to learn one language, is to learn two, or better still five... The fact that something 'obvious' in language 1 isn't in language 2, usually points to something fundamental. Not necessarily wrong (except for VBA / VB6 which in my opinion are pitiful) but should be different enough to make you start questioning a whole range of now foolish assumptions.

Tony Hopkinson
Tony Hopkinson

my business head argument... hmmm, more work needed obviously... :p

RayJeff
RayJeff

READ MY FIRST POST ABOUT HOW ACCESS SAVED MY DIVISION-THAT WILL FILL IN THE GAPS OF MUCH OF WHAT I SAY OR DON'T SAY IN THIS RESPONSE. The accreditation project I worked on, it was there before I came onboard. So it would obvious to say that the database I developed wasn't just a thought to when I started it. In many meeting's with MIS director of the college when discussing the various requirements of the database, there would always be debates between the director and I because of the decisions I made on the database. Basically the director thought my way was wrong and their way was right. Well, the problem is that when the accreditation process started, my then supervisor went to the MIS director to start the ball rolling on developing a database (this was almost 3 years before I got there). Well, nothing happened. Not even gathering the requirements...nothing! Now, because the accreditation was the college's top priority, ALL RESOURCES was put forth in support. So, you would've thought even if the MIS department could not do the job, then they could have gotten a consultant or a company to come in and develop the database...nothing happened. When I was hired, I had to jump in with everything I had to catch up to speed. This gave me an insight the MIS director didn't have. And plus, corresponding with specialists and consultants in that area. But, here's the real kicker. I left the college in 2006. 3 years later, the database I developed isn't even used anymore. A company was brought in and they created a new database, that I'm sure was based on my original work. SO, do you know what that says to me? The college got my work for "free" and used my work to start all over because at the very beginning of this tale, they were too lazy to even do the work of developing a database.

Tony Hopkinson
Tony Hopkinson

The two to be wary of are No business case at all. And the off load. One of the beauties of access or something similar is you can use it to build / prove a business case, and get something real out of it while you are doing it. Nothing the bean counters like more than collecting Y enabled us to save Z. It makes it much more credible to say collecting 2Y will save us 4Z. Those guy like real numbers. I've had months of development paid for by doing a phase 1 iteration. One's projected annual savings went to ?100k from a weeks effort, getting another two months to potentially double that, was easy. I believe all we were saying that just because it doesn't use IT resource doesn't mean it's free. Personally I'm a nice guy who likes to say yes, the professional side of me requires the but....