SAFE SQL Update 6.3
While we're awaiting SAFE 7.0 that still doesn't mean we're not continuing to polish SAFE/SQL Version 6. To that end, the next update to SAFE/SQL 6.3 is now available. RSS Users will receive this automatically. Version 6.3 is primarily a maintenance release (it fixes 'bugs') but it does have several 'little' things that can be real time-savers. These changes/fixes include:

New Features

Fixes

Hope that gets your blood racing! Next time we'll have more on SAFE/SQL 7. Until then!
 

2nd Notice: Security Update: Ollie/WebSAFE E-Mail Cloaker!
Ed Note: We've had good response to this, but not as much as we'd hoped. Again, we consider this an extremely high priority for all WebSAFE/Ollie customers to avoid spam and any number of possible e-mail based intrusions.

Ever wonder how the spammers get your e-mail address? One of the most common ways is through automated harvesting programs called 'Spiders' or 'Bots' which search the web all the time looking over HTML pages (the pages on your web site) for e-mail addresses. In other words, they read your pages and when they find an address, they add it to their database.

A new update for Ollie is now available which cloaks all e-mail addresses used in Ollie/WebSAFE so that they are unreadable by these harvesting programs. For users of Standard Ollie, there is no charge for this update. For those using customized versions of Ollie, there will be a 1 hour labor charge to update any customized HTML pages.

Due to the ever increasing spam problem, we strongly recommend that all Ollie/WebSAFE users obtain this update immediately.

Cute FTP For Remote Support!
Some of have asked for an alternative to using iClose-Up for remote support. OK, so here's your alternative: Cute FTP6 Professional from GlobalScape

And here are the conditions:

1. You have to have a copy of CuteFTP 6.0 Professional. That shouldn't be too tough

2. You have to have a Static IP address available for support

3. You have to be running Windows 2000 or XP or Server 2003

4. You have to have Terminal Services running.

Why CuteFTP? Why not any FTP software? For the same reason we have always used iClose-Up: speed!  Due to the huge file sizes of databases, regular internet connections (even DSL) are simply not fast enough to send/receive information from SAFE in a timely manner. iClose-Up has always had the ability to transfer files at many, many times the speed of your internet connection using a proprietary technique that has yet to be equalled. With version six, Cute FTP has now added a similar capability over FTP, however this capability only works if CuteFTP is present on both sides of the connection.

There is also the question of familiarity. Frankly, we've grown a little tired of having the exact same bleedin' argument with every goofy IT person about iClose-Up. Because they don't know the product, many tend to fear and resent it, even though it remains the safest and fastest way to transfer files back and forth. But, fine, here is an alternative with which your local 'computer guy' will feel comfortable and addresses our need for speed.

I think you'll get from the above that this in no way, implies that we are in now way less happy now with iClose-Up than in the past. It is still the best way to go, but if you need an alternative, use CuteFTP. And if you're currently using iClose-Up there is zero reason to even think about switching.

Last Call: Another Fantastic Faxback Offer!
Those fine folks at FaxBack have asked us to pass on the following  NET SatisFAXtion fax server, "Powered with Brooktrout" fax card promotions.  From now, until the end of April, take advantage of these terrific fax packages:

---Faxback is the low cost, industrial strength fax server that is 100% integrated with SAFE. Send invoices, POs, reports, in fact, any document from SAFE directly from any user's desk either singly or in batches as easily as printing! SAFE handles the routing to all relevant fax numbers!

---Faxback allows you to receive faxes without paper. In fact, you can now receive (as we do!) all faxes directly into PDFs. A great way to have a -complete- audit of all incoming and outgoing materials!

---The total cost of ownership, both in terms of initial cost, cost savings over time and increased efficiencies are significant.

For more information, contact us or go to www.faxback.com
 

Ciaran's Corner: The Annual Update Policy Rant!
Ah, Springtime! The time when a man's fancy turns to thoughts of fixing bugs. This week I have been told of several customer complaints about known bugs in SAFE and so, through the magic of Ctrl-C and Ctrl-V I have been able to lift my rant (...er policy statement) wholesale from four years ago and re-state our policy on updates to SAFE. (Actually I do have some comments to add to this if you make it through the policy statement.)

There are four factors which guide the development of SAFE.

1.    Bugs:    We are obliged to fix all known flaws in the software, aka 'bugs'. Often when users report a bug, they next sentence out of their mouth is: 'when will it be fixed'. And by that they mean: 'in how many minutes!'. There is a moment of silence before the tech breaks it to them: 'July'. Why? Two words: Version Control! Usually, a bug creeps in because of SAFE was not tested under enough conditions. Every time we 'fix' something, another round of testing is required. This takes time. It would be irresponsible to throw out a 'patch' to the software for every bug found.

Also, if we did something like that, it is likely that virtually every user of SAFE would end up with a slightly different version of the software. This is known as the 'Microsoft Service Pack Syndrome'. Microsoft used to issue 'patches' almost daily as bugs were reported in NT. The pace of these patches was so fast that users could not keep up. Plus, each patch tended to introduce as many problems as it corrected. Worst of all, users tend to develop 'patch fatigue'. With so many patches, users would begin to not bother installing them all, which is largely why NT gets hit by so many Internet hackers, not because there are so many current flaws, but rather that most users haven't bothered to install all the patches! So, the prudent approach is clearly to send out scheduled releases (as we do: every three months), even though this may seem like an eternity if you are bitten by one of the known bugs.

2.    Backward compatibility:    It is very important that new features not cause existing features to malfunction. Unless there is an overwhelming case to be made for the new feature. When we are asked 'why does such and such work that way', the answer often lies in maintaining some existing features. I don't think a day goes by that we don't wish we could start with a fresh page for each release, but that's how it is. Abandoning compatibility with any previous feature in SAFE is just about the same thing as saying 'Goodbye Mr. Customer!'

3.    New features:    A couple of questions usually come up along this line:
    a.    How do you decide what to change? User feedback: Since we are not forms distributors, we
    have no pre-conceived notions of how SAFE should work. We get everything from you. Which begs
    the question, of how we get that feedback:
    I.   Beta Testers:  If you beta test, your voice is heard LOUD AND CLEAR. Everyone who beta
          tests, in large part gets what they want. It's the least we can do. Many of you talk about how
          you 'partner' with your vendors and customers. Well, we consider our beta testers our true
          partners..
    II.  Written requests: If you are willing to take the time to write, then we will listen.
    III. Oral anecdotes:  Feedback you give to our trainers or reps at trade shows. Frankly these are
          the ones we argue about a lot. Reason being, many of us feel strongly that users who beta
          test and send in suggestions should be given preference over ideas chatted about over the
          phone or during training. Often it is those who natter the loudest over the phone about a
          missing feature who are the least willing to write down and submit their request. They expect
          us geeks to remember all these things.

    b.     When will you add it?    We maintain a schedule for updates which goes out nine months.
            Changes are made according to need (bug fixes), opportunity (how easy it would be to
            implement) and general usefulness (based on feedback from users). The programmers
            look at all these and put them on a big scheduling board. This allows us to plan the

    d.     Why do I have to pay for it? You and I may agree that a feature is useful,  would not
            harm any other users, and is easy for us to implement. But that feature may still not
            make it into SAFE right away. In that case, vote with your wallet! Often times when
            we ask users to pay for a feature, it  is simply because it has not been requested by
            other users. Whether or not they might find it useful is only relevant if you are willing
            to wait for us to check with the 'body SAFE', get feedback and schedule it. This all
            takes time.

4.    Removing features:    It is important that we, from time to time, remove features which are
       no longer used by the vast majority of users, or features which are used by only a few users,
       and are not life-threatening. Otherwise, the program gets unwieldy. Invariably, two days after
       a new release, we'll hear from someone who is unhappy that a particular feature changed
       or has been removed. This usually happens because we had no idea they were using it!

How Can I Change The World?
Well, you probably can't, of course. But you can exert undue influence and power over the development of SAFE! How you ask? Well, I already told you. But for review:
1.    Sign up to beta test (I'll have more on this next time!)
2.    Send us a letter or e-mail with your suggestion. Please include some background on what it should
       do matters, how it will benefit distributors, and so on. I'm told to mention that bribery is not strictly
       necessary at all.

How things change. And how they stay the same! Microsoft still battles with version control issues and trying to be responsive without introducing those nasty regressions (aka fixed one thing then broke two others). The only thing I would like to add to the above is in the 'How Can I Change The World Section. I really should have added a number three:

3.    When you do find a legitimate flaw in SAFE, it is extremely important that we:

a. Truly understand what is going on (ie. that the problem is well-defined and well-documented).

b. That we can reproduce it.

It never ceases to amaze me how a few of our customers (just a few) will report a problem, get all flustered, upset, etc. and spend all kinds of time going on about how much it is hurting them, but never take any of that time to document it in such a way that we can actually do something about it. Look: we are all in this together! How can we convince you that we dearly want to make SAFE perfect. But we cannot do it without your help.

For example, let us say that we're presented with two customer problems: Problem #1 is presented with screen shots, specific examples and keystroke by keystroke explanations. Problem #2 is presented as 'here is a problem, deal with it; it's driving me crazy.' Now, think fast: which one will get our attention? (If you said, 'whoever screams loudest', you could not be more wrong. That customer is only shooting themselves in the foot.) The harsh reality is that there will never be enough time for us to chase down vague complaints. Never. And the customers who are most willing to help us will almost always get their issues dealt with first.

If nothing else, I would like everyone to understand that we knock ourselves out seven days a week to make SAFE the best it can be. Really. Our policies are designed to balance the needs/wants/desires of all our customers so that we can come as close to perfection as possible given our resources. But, that said, we cannot do it without your active participation. Like I said, we're all in this together.

Til Next Time,

Ciarān Marron
Technical Support Manager
cm@suntowersystems.com

---

THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. The information contained in this document represents the current view of Suntower Systems on the issues discussed as of the date of publication. Because Suntower Systems must respond to change in market conditions, it should not be interpreted to be a commitment on the part of Suntower Systems and Suntower Systems cannot guarantee the accuracy of any information presented after the date of publication. INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'AS IS' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND FREEDOM FROM INFRINGEMENT. The user assumes the entire risk as to the accuracy and the use of this document. This document may be copied and distributed subject to the following conditions:
1. All text must be copied without modification and all pages must be included.
2. All copies must contain Suntower Systems' copyright notice and any other notices
    provided therein
3. This document may not be distributed for profit.

---

End of E-News From The Suntower, Volume VI #9