By Susan Sales Harkins and Gustav Brock

Nothing frustrates the full spectrum of Access users — from casual user to developer — quite like a corrupted database. With a little know-how, you might get lucky enough to repair the database or at least recover the data. Sometimes, a third-party product that specializes in recovering data from a corrupted database can help. But you could end up rebuilding and re-entering data. (Or rather, your replacement will rebuild and re-enter it.)

A more proactive approach to the situation is to avoid corruption in the first place. Here are some strategies for preventing your databases from becoming corrupted.

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

#1: Split your database

If more than one person will access the database, split it into two pieces: a backend that stores the data in tables and a front end that contains everything else (forms and reports). Access has a wizard that holds your hand through the process so there’s no excuse not to split a shared database. Name the two ends appropriately. Remember, the backend contains your “gold” — your data. With the data and interface objects in separate databases, you can easily replace the front end from a backup, if necessary. In addition, this setup makes enhancements easier to incorporate into your system.

There is some discussion about whether the front end should be stored on a network server (and shared) or on a local drive. This decision really has no impact on corruption, so the choice is yours. If possible, consider write-protecting a shared front end. If the worst happens and something destroys the front end, simply obtain a fresh copy of it to replace the broken one and reboot the local system.

#2: Store temporary tables in a backend

If a database creates, populates, and then deletes temporary tables, keep those tables in a separate backend database to prevent bloat. Name the additional backend accordingly, making its purpose obvious. This additional backend can be shared or local.

#3: Don’t use memo fields

Avoid using memo fields if possible. They often, indirectly, cause corruption. Even though the database in these cases often can be repaired, some content in the memo fields might be lost. If you need memo fields, keep them in separate tables and create a one-to-one relationship to the parent table(s). Even better, move memo tables to a separate backend database file and name the file accordingly, to indicate its purpose.

#4: Don’t store picture files

Usually, you shouldn’t store picture files in a database. If you must, treat them the same way you would a memo field (see #3). Access has no problem attaching tables from multiple backend databases.

#5: Create temporary tables to speed up queries

If you run complex or nested queries (where one query pulls data from others that hit still others), Access may write a lot of temporary data that you never see. Most often, this happens when a query that works with a small amount of data performs slowly, putting stress on the JET engine. If Access chokes during this process, you can end up with a corrupt backend file.

To prevent this problem, write some of the temporary data to temporary tables. There’s no universal propecia new york method to recommend. Analyze the specifics and run some tests to find the best solution. However, sometimes the use of just one temporary table can minimize the chance of corruption and speed up the queries by a factor of 10 or more.

#6: Be careful with wireless networks (WiFi)

A connection may work fine, but multiple users or powerful neighborhood networks (or other noise sources) can abruptly cut off the connection. That can corrupt the database file if you are writing to it at the time. This type of interference isn’t a problem if users are mostly reading from the database.

#7: Be careful with WAN connections

A WAN connection that covers any connection from a local system to a server via the Internet can cause trouble. Reading the database may be slow but acceptable. However, writing to the database is error prone and can cause corruption. When bottlenecked traffic interrupts data transfer, Access times out, believing the connection has been lost. This behavior usually leaves the backend database in a corrupted state.

#8: Don’t put Mac and Windows users on the same network

If Mac and Windows users share the same network and experience problems, establish a separate network for database users. Macs are extremely noisy, and typical Mac applications generate vast amounts of network traffic when moving large graphics files and printing. In a shared environment, use only high-quality network components.

It’s best to keep the database traffic separate from the graphics traffic, as much as possible. You can accomplish this by allowing administrative workstations to connect directly to the server with the shared database via a local switch.

#9: Troubleshoot network hardware

If corruption just happens from time to time, you may have to deal with a network hardware issue. First, try to narrow down the workstation and swap the error-prone station with another. If the issue follows the workstation, you know that’s the source. It might be easiest to get rid of the workstation.

If the problem isn’t specific to the workstation, the error is most likely to be found in the connection from the workplace to the network switch — including the actual switch port. If the cable’s in good shape, swap the ports between the workstations. If the error source now swaps too, replace the switch; if not replace the cable. If cables aren’t permanently installed or don’t cross from floor to floor, you can try replacing them before swapping workstations.

#10: Check the server’s configuration

Sometimes, the configuration for the server where you’ve stored the shared backend database file is the culprit. You’ll need a specialist to track down and resolve this type of problem. There are several possibilities, from server parameters to a malfunctioning disc controller to a misconfigured RAID array.

You can temporarily move the backend file to a different location, like one of the popular NAS devices or a shared folder on a workstation. If the problem with corruption goes away, call the specialist. If not, the corruption’s source is somewhere else (#1 through #9).

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 propecia muscle growth 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.)

Microsoft Access may not be the king of databases, but it does offer a number of advantages over solutions like SQL Server and Oracle in certain situations. Access guru Susan Harkins counts the ways.

Nothing starts a fire quicker than saying, “Hey, let’s use Access. Yeah, Access can do it!” Oh my… just thinking about it makes me want to don a fire retardant pocket protector. Seriously, though: Access elicits real passion. Developers and IT folk either love it or hate it. There’s no reason why you should use a tool you hate, but you should strive to use the tool that’s best for the job.

The truly smart and effective IT professional knows that there are many tools. The key is to know which database engine is the best for the job at hand. Why throw massive resources at a simple need? In other words, you don’t want to pay for a Rolls Royce engine if you’re building a go-cart. Knowing when and when not to use Access will help your budget and make you look good, whether you’re a freelance developer or you’re managing IT resources.

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

#1: It’s cheap

Access is a desktop database and its place in the hierarchy — layered between Excel and SQL Server — determines its price. Access costs the same as any other desktop application. Acquiring a copy of Access won’t require a loan or a call to investors.

The large client-server databases, such as SQL Server and Oracle, require specific hardware and expensive licensing. After the project’s up and running, a client-server database needs a dedicated administrator. Access requires none of that.

On the other hand, Access is a desktop application. That means that everyone who uses a customized database application needs Access installed on their local system. All those copies of Access can be expensive. One alternative is to invest the time and money it takes to turn your database into a runtime application. (Access 2007 doesn’t support this option.)

#2: It’s easy

Anybody with just a bit of time and reasonable intelligence can learn to use Access. It doesn’t take weeks of classroom instruction and then months of mentored on-the-job training to acquire the skills necessary to create and administer a database. It’s safe to say that most Access databases have one user and they live out their lives on one system. The user generally creates the database in his or her spare time. The casual user with no professional database or development skills can get data into an Access database and then manipulate that data without blowing up the building.

A good database grows and a bad one dies — regardless of the data engine that’s driving it or the skill set of the person who created it.

#3: Development costs less

Many developers make a good living creating custom database applications in Access. (Call me, let’s talk.) However, in general, they charge less than SQL Server and Oracle developers. Moreover, the development costs are just the beginning if you go with SQL Server or some other client-server software (see #1). If you really want to use Access and you’re smart, you’ll see that an enthusiastic and eager employee gets the right training. Then, pass out all that money you save in employee bonuses.

On the other hand, it doesn’t matter how much money you save initially, if you use the wrong database. Don’t let money be your only consideration or you’ll surely regret it. For instance, the security model is minimal (and doesn’t exist at all in Access 2007). Recovery isn’t as easy, either. Don’t use Access for mission-critical applications unless you really know what you’re doing — and even then, it might be a good idea to keep your resume updated.

#4: Prototyping is a snap

Access is a great way to show fast results for the impatient client or boss. You can collect a little data and in just a few hours (or days) wow them with a few neat forms and reports — I can hear them ooing and ahhing already. You don’t have to use Access to build the production database, but you can ease client concerns by showing that you understand their needs. Access lets you get results fast and often with little to no code.

#5: It’s easy to upsize once it outgrows Jet

People who control the purse strings aren’t usually willing to dedicate resources to developing a noncritical database. Most of the time, you’re on your own. However, that doesn’t mean that a good design won’t grow and evolve into a truly useful tool. If that happens, you can upsize an Access database to SQL Server. You don’t have to start from scratch.

Still, Access is limited to 2GB. Even if the database’s purpose isn’t critical, the amount of data alone might force you into the arms of a more robust engine. Realistically, you probably won’t run into that limitation too often. If you do, you can eliminate Jet from the picture and use an Access front end to link to SQL Server data.

#6: It’s a one-time fling

Not every custom database has a long shelf life, but that’s not because it’s bad and dies an agonizing death. Sometimes its purpose is timed. For instance, generating, collecting, and analyzing questionnaire data can be a big job, even for Access, but a single questionnaire has a limited lifespan. If you’re going to use a database once, or for only a short time, use Access if possible.

#7: It can provide a quick fix

The best solution for your needs might be a powerful client-server database such as SQL Server. However, while you’re waiting — and you will wait — how’s the work being done? You can use Access as a quick fix until the more robust version is ready. You’ll have to compromise, because if you really need SQL Server, you’re not going to get the same work done in Access. But you might get portions of the work done. Analyze the overall tasks and see what components you can automate in Access, at least for the time being.

#8: You want to change what?

Access is flexible, and that’s one of its best attributes. Even if you can put a custom database together in a matter of weeks, needs are likely to change. Almost immediately, the user or client will think of something they want to add or change. If you designed the database well in the first place, Access will handle enhancements and changes without complaint.

#9: It talks to Office

Access is part of the Microsoft Office suite, so it plays well with the other applications. Users can quickly and easily export data from or import data into Excel or publish reports to Word. In addition, it shares a similar interface with other Office apps, which helps new users feel more at home and diminishes the learning curve.

#10: There’s less code!

All things being equal, Access can get the job done with less code than SQL Server (or some other client-server database). In addition, VBA is an easy language to master.

#11: It offers connectability

Access offers an affordable solution for individual users and smaller teams. Despite protests from some member of the IT club, you can even use it across a network if you know what you’re doing (file server solutions on a local network).

On the other hand, Access isn’t optimized for the Web. Although a skillful developer can use Access on the Web, in general, it just isn’t a good idea. Jet can’t handle large numbers of simultaneous users, unless of course you really know what you’re doing — and that level of expertise is really closer to magic than development. It can be done, just not by many.

propecia missed dose

When you need to round up data on when your customers last placed an order, an Access query can do the trick. Here’s a quick walk-through that shows you how.

Orders have fallen in the last month and you are wondering whether you should send out another promotion. You decide to send one promotion to customers who have ordered recently and another to those customers whose last order was more than a month ago. Customers who haven’t ordered in six months will be excluded from the mailing. To find out when each customer placed their last order, follow these steps:

Figure A

1. Right-click the Query grid and select Totals (Figure B).

Figure B

1. Click the drop-down arrow of the Totals cell under the OrderDate field and select Last (Figure C).

Figure C

propecia merck
1. Click Run.

The query Datasheet view lists each customer’s name and last order date.

If you build a little space between your borders and text, the results will be better looking and easier to read. Here’s a quick way to fine-tune the spacing so it’s just right.

Did you ever wonder why it looks like you need to insert a blank line between the top border of your paragraph and the paragraph text? By default, Word leaves only one point of line spacing between your top border and the text, which can look a little crowded (Figure A).

Figure A

You could click before the first word in the paragraph and press Enter, but that might not give you the exact spacing you want. Let’s say, for example, you would like 6-point line spacing between the border and the paragraph. To achieve that formatting, follow these steps:

Figure B

1. In the From Text section, click the up arrow of the Top box until 6 pt is displayed.
2. Click OK twice (Figure C).

Figure C

Now your text will be situated six points below the top border, as shown in Figure D.

Figure D