Incident tracking

[N. A. Corbier]

We use E911Help and E911Stat. My Security Manager wants me to find out more info on the update. Can anyone shed some light?

Imagine E911Help, in a window, with cheezy graphics. Same thing, just happens to run in Windows 3.11 and up now.

You can go to RAD Software and download a demo of the "new" E911Pro system. Honestly, though, it is not worth the $500 dollars they want.

You can make the same thing with your copy of Microsoft Access, without VB Script even, and a copy of "Understanding Microsoft Access 2000."

While I personally loathe Access for database functions (its slow and the more you plug in, the slower it gets), even Access is better than some Visual Basic program from 1995.

[Professional Rent-a-Cop]

At my inhouse job, we use PPM 2000 to monitor systems controls, boilers/chillers/pumps, and also track our residents through the trace system. We can electronically open doors and buzz people in through it, and all of the building access cards issued to staff and residents is set up in PPM 2000. It's a wonderful program and we love it. Our entire entraguard access control system is wired to PPM 2000, and this is our main computer unit. Our report writing, however, is about thirty years late on technology: we still use a type-fax writer that automatically prints via fax wiring to our office, management's office, general manager's house office, and the HOA Board President's home. It kinda makes it a little bit of a pain as all reports written are final; if you screw up a report, you have to also type-edit it in the next report entry. Also, you can easily type a non-professional report by accident. As in you are typing something about your shift, and miss typing the " f " key. I don't think I have to put in here what that spells.........

[SecTrainer]

I didn't bother looking at the DLL, and really didn't want to install it on this PC. Thanks. There still is life for VB5 applications, I guess.

Well, if you want to call this "life"...

[FireEMSPolice]

This was an old DOS program written in BASIC called 911Help, transported to Windows.

This version, which is their latest, is touted as being a "new platform". However, it installs MSVBVM50.DLL, the runtime files needed to run applications written in VB5, so I guess that answers the question pretty definitively.

We use E911Help and E911Stat. My Security Manager wants me to find out more info on the update. Can anyone shed some light?

[N. A. Corbier]

I didn't bother looking at the DLL, and really didn't want to install it on this PC. Thanks. There still is life for VB5 applications, I guess.

[SecTrainer]

E991 from Rad Systems is a Visual Basic application, I've ran the demo program and actually laughed at it. No wonder it crashes so often, it looks like it was written in the 1990s.

SecTrainer, if you get a chance, take a look at it. Is it VB or Visual Basic for Applications? My bet is VB 3-5.

This was an old DOS program written in BASIC called 911Help, transported to Windows.

This version, which is their latest, is touted as being a "new platform". However, it installs MSVBVM50.DLL, the runtime files needed to run applications written in VB5, so I guess that answers the question pretty definitively.

[N. A. Corbier]

What are you talking bout?

Davis002, you have a PM!

E991 from Rad Systems is a Visual Basic application, I've ran the demo program and actually laughed at it. No wonder it crashes so often, it looks like it was written in the 1990s.

SecTrainer, if you get a chance, take a look at it. Is it VB or Visual Basic for Applications? My bet is VB 3-5.

[Bill Warnock]

To round out your search, try PPM2000. Look into your multiple applications and your architecture and see if they have what you need now and what you will need in the future.
Enjoy the day,
Bill

[FireEMSPolice]

I just got my company to tUpgrade to E911 Pro. We used to and still do have paper logs (until the E911 Pro is phased in completly). I figured that atleast 911 pro would be better then nothing. I mean i was watching disptach one nght flip through papers to get info. So it is a start to have E911 Pro. We still have some people who dont like it. But there is only one or two of them now of our 70 person staff. It is not as good as 10 000 dollar systems but for what you pay for and our needs it works fine.

Let me know how it works. Ours sucks. Always crashes.

[Arff312]

I just got my company to tUpgrade to E911 Pro. We used to and still do have paper logs (until the E911 Pro is phased in completly). I figured that atleast 911 pro would be better then nothing. I mean i was watching disptach one nght flip through papers to get info. So it is a start to have E911 Pro. We still have some people who dont like it. But there is only one or two of them now of our 70 person staff. It is not as good as 10 000 dollar systems but for what you pay for and our needs it works fine.

[FireEMSPolice]

Oh, man. I looked at that stuff, and was like, "Wow, that crash course in Visual Basic 3.0 paid off!" That they charge $400 dollars for a souped up Visual Basic for Applications or Visual Basic program amuses me greatly.

What are you talking bout?

Davis002, you have a PM!

[N. A. Corbier]

Oh, man. I looked at that stuff, and was like, "Wow, that crash course in Visual Basic 3.0 paid off!" That they charge $400 dollars for a souped up Visual Basic for Applications or Visual Basic program amuses me greatly.

[FireEMSPolice]

We use E911 made by Rad Software. Its a worthless program.

[Squidly]

Thanks Sectrainer... I will take a look and see what we can do!!
Shale keep you posted!!

[SecTrainer]

Another point is the legality of the data/report in a court of law. I know with our DB the information could be changed at a later date. There are other systems that this could be done also. When looking at reporting systems there needs to be fool proof reports, such as if a field is blank it alerts you, when you hit save that is the end of the matter and it can not be tampered with at a later date etc.
The system we have is ok but obsolete fields can not be deleted such as old staff etc. if you delete it you lose the information in the old reports.
Agreed I hate access but I have a resonable knowledge of the system. But I still havent worked out how to overcome these problems!! Anyone??

A few suggestions, if I might:

1. Presuming that your data (reports, etc.) are being accessed by bound forms, you would set the "AllowEdits", "AllowDeletions" and "AllowAdditions" properties of the data retrieval form(s) all to NO. You can do this via the form's property sheet, or by way of a macro or Visual Basic.

As a matter of good DB practice, always use separate forms for data entry (and report creation) and data retrieval. In other words, a data entry form would never access existing records anyway, and would have at least the "AllowAdditions" and "AllowEdits" properties set to "YES" rather than "NO". You can think about whether you want "AllowDeletions" set to "YES" or "NO".

The data retrieval forms are the ones that would have the properties set to "NO" as noted above. All the user can do with such forms is to view/print data; they cannot change it.

2. You probably would not like a database that allowed NO editing via forms. You can create data editing forms that will only function on entry of the password of certain users like supervisors, as well.

3. There are a number of ways to verify that fields in a data entry form have not been skipped (do not have empty values), as well as to make sure that the values entered are of a certain type, format and range. These are discussed under topics like "data verification", etc. in most decent Access books and most are quite easily implemented.

Some methods of data verification are established at the time of table design, but can be changed afterward. Others involve the data entry forms, forcing the user to move through the form in stepwise fashion and preventing them from leaving a field until there is some "change" (or entry) to the field.

4. Finally, assuming that at least some limited editing capabilities are desirable, there are ways to audit, or track, such changes to Access records. With audit capabilities, it is then sufficient (and better) to be able to testify that the audit trail shows that the report has not been changed, or how it was changed. "Yes, the record was updated on 5/15/2006 to correct the subject's date of birth. There have been no other changes to the record." This kind of testimony will NOT invalidate the legality of a report, but rather would tend to corroborate it because no one will ever believe that there is ABSOLUTELY no way to ever change data in a database and opposing council would have a field day if that's the approach you try to take. Better to say "Well, yes...of course you can change certain aspects of our records, but we know about it when a change is made, what the change was, who made it and when because we have an audit trail."

Building audit features into your database, even an existing one, can be done fairly easily, but it does require a modest ability with VBA. You could build your main application yourself using basic skills, and then "job out" programming the auditing function of the database. It's not a major project. Basically, it amounts to the creation of a table that uses a fairly simple routine to track changes "behind the scenes", while also recording the user, date and time of the change. The user is unaware this is going on.

Since such audit tables can grow very large, the auditing routine will need to incorporate some maintenance elements, such as the ability to "dump" to a compressed file, removable media, etc.

Of course, if you add audit capabilities to an existing DB, it will only be able to say what happens to your records going forward, not what's happened to any records before it was implemented.

Hope this helps!