This is the second of several articles in a special series introducing our newest product offering: AVAproject Fusion.

Fusion is about mastering your data. Information from AVAproject or virtually any other Windows-compatible data source can be brought together, manipulated, reported on and reformatted for use in other applications. See your data any way you can imagine it.

Last month, we focused on the process of bringing project files created in AVAproject into Fusion. Now we begin to explore why we're doing it. All the information entered in AVAproject culminates with the creation of the Priced Material Lists. For both Division-8 and Division-10, the net result is the same. The software creates a detailed listing of each and every component of the project. Even beyond this, the Material List identifies the way certain project affect others. For example, hardware items are not only listed themselves, but also the preparations required to accommodate them on the doors and frames.

AVAproject Fusion takes the familiar Material List to an entirely new level. In addition to the Material List on the Navigation Bar, is a brand new data table, the "Combined Information Pool".

At first glance this table may look identical to the Material List, but it is so much more! It is an enhanced Material List that links back directly

to all the data that was used to create it. As its name implies, this "Combined Information Pool" is exactly that – it is a fusion of all the Openings Schedules, Hardware Groups, Accessory & Misc. tables and other related data sources all available in a single, massive table of data.

"Right-clicking" on any column header will yield the standard "Insert Column" option, but with a huge added feature. In addition to the standard Material Columns, all the related data columns from the various source schedules are also offered.

For all those users that have requested additional columns to be added to the AVAproject Material List, this is what you’ve been looking for - and so much more. Absolutely any column from the

Hardware Groups and Openings Schedules can be added to this new and improved Material List!

The advantages however, don’t stop with simply displaying this data.

These columns can also be used to group, sort and use in the creation of reports and tables within Fusion. In the next article, we’ll explore "Filters" and how they can be used to extract specific information from the projects.

____________

Many of the concepts discussed in this article are expanded upon in the AVAware publication: "AVAproject Fusion: Theory of Operation". In it, data structures and the interaction between project components are illustrated in much greater detail. This comprehensive document is available in the Downloads section of the AVAware website.

One of the most interesting aspects of running a support department is observing trends in customer inquiries and identifying common points of confusion.

By far the most common question where hear in both the sales and support departments is "Is this a 'network application'?" The question seems simple enough: "Yes" or "no"; "it is" or "it isn't". Simple, right? Not so much.

To a software developer, the term 'network application' or 'network capable' really means nothing at all. It's equivalent to asking if your new car is "road capable". There are so many different ways that a piece of software can be installed on a network and even more ways that its resources can be distributed on said network, that a "yes" or "no" answer to this question tells you absolutely nothing.

In most cases, when a sales person does answer you, they are either guessing at what you're referring to by your inquiry or more likely just giving you the answer they believe you want to hear. Quite honestly, virtually every piece of software is a 'network application' or 'network capable' to some degree – it just depends on how you look at it.

If we were to attempt to come to a meaningful answer to this age-old matter of network compatibility, we would be best to begin by looking at the various components of both the network and software in question.

The Network

While there are as many different networks configurations as there are stars in the sky, all of them can be broken down into three major groups:

Peer-to-Peer Networks: This type if network is most commonly found in homes or extremely small offices with only a few users. They consist of several computers, networked together, with no designated "server" or "main" computer. Based on security settings, each PC can optionally share its files and access files from all the others. There are also usually printers and an internet connection that is being shared by all the machines. What defines this type network however, is that no PC is more important than any other. Each PC is intended to be used by a person and there is no established central server on which the other PC is dependent. If any machine goes down, the others are unaffected.

Server-based Networks: This type of network is most common in commercial settings and is defined by one or more common "servers" that are accessed by some or all of the PCs connected to the network. Often the PCs within a server-based network also have peer-to-

peer functionality in that they can access each other's files, but the primary intent is to have shared resources stored on servers. This is essential to maintaining optimum performance. Unlike peer-to-peer file-sharing, servers dedicate 100% of their resources to "serving" files to the various users at top speed. The important thing to remember is, when the servers go down business comes to a screeching halt.

Thin-Client Networks: This is by far the least common and most radical configuration you're likely to find. In this environment, the only computers on the network are the servers themselves. They don't just serve files however – they also serve processor time. There are no PCs needed on the user's desktops, just "thin clients" (otherwise referred to as "appliances" or "dumb terminals" because they contain no software or operating system). All they can do is connect to the server and allow you to control software that is running on them. The servers "slice" up their processor resources and run the software application on behalf of each user. Although extremely simple to install and maintain, the drawbacks to this configuration are huge. Performance typically suffers because users are ultimately sharing a processor. In addition, those thin clients are completely useless when the server goes down.

The Software

Although this can vary between software packages, most can divide their resources into three major categories.

Software: The first major component is the software itself. This is usually located in the "Program Files" or similar folder and contains the program itself.

Static Data (i.e. Libraries): Often thought of as part of the software installation. It is the data component of the software program itself. This data is never changed by the users. It the case of architectural industry software this would include things such as location libraries and manufacturer catalogs.

Dynamic Data (i.e. User Files): The final component, the files that the users create. Their individual data files and the files that are shared amongst multiple people in the company all fall into the

general category of "dynamic data".

Where Does it all Live?

When installing software in a network environment, the big question is where to locate each of these three major groups of files. Any one or all of them can be located either on the server or on any of the individual PCs. As long as any one of them resides on any machine that is accessible by others on the network, you have yourself a 'network application'. Starting to see why this term is so ambiguous?

The next bit of news is really no more encouraging. There is simply no correct answer as to where these components should be situated. This is entirely a matter of opinion. For each choice, there are pros and cons. Every software developer will make decisions based on the way they configure their software based on their own priority structure. Trying to examine every conceivable combination and option is beyond the scope of this article – people have written entire books on the subject. But we will look at some of the basics. The first question is where to install the software application itself: on the server or on the individual desktops. Each one has its advantages, and it's up to the user to decide what is most important for them.

AVAware has followed the lead of application developers such as Microsoft and Adobe Systems. We install software and its static resources on the individual desktops and the user data (that is intended for sharing) on the file server. Every company has their own reason for what they do, these are some of the reasons for our choices:

Installing software on the server provides only one distinct advantage: ease of management. Software only needs to be installed and updated in one place. Generally speaking, I.T. people love this configuration because it makes their jobs a lot easier. But it does come at a significant price – many people, us included believe that this type of installation does not serve the best interests of the company as a whole.

Installing software and its resources on the users' local machines has a number of important benefits:

At the end of day, the choice is up to the buyer. Those that offer server-based applications may have their own reasons for doing so, but the important thing to take way from this article is the fact that all "network applications" are not created alike. Many more questions need to be asked before you can arrive at a useful answer.

We welcome any questions, comments or suggestions about any topic mentioned in this edition of AVAwire. Please visit our website for more information, or contact us directly at (416) 239-9099.