Electronic Forms software that integrates well with Access

[Bob Alston]

I am looking for electronic forms software that would integrate well
with MS Access.

I have a client for whom I built a client database to replace and update
one they had that was obsolete and not doing what they want.
They are wanting to move on to the next step and automate most of their
forms. some are boilerplate forms that are simple printed without
change. some are boilerplate but require signatures from client and
rep. Others provide for entry of quite a bit of data.

All forms will be filed manually in hardcopy (yes I am trying to bring
them into the 20th century, but then they quote Federal Goverment
requirements... ). Some of the data from the forms will need to
preferably be populated from the database, name, phone, etc. Some forms
will have a few fields recorded to the database as well as the form.
Some forms will have many fields recorded to the database.

Obviously it would be desirable to keep the completed forms accessible
electronically (and hopefully the long term repository once we get rid
of all the paper files).

Anyone have suggestions for software that have used for something
similar with good success?

The client is a nonprofit so price is a factor.

Bob

[Larry Linson]

"Bob Alston" wrote

I am looking for electronic forms software
that would integrate well with MS Access.

I have a client for whom I built a client database to replace and update
one they had that was obsolete and not doing what they want.
They are wanting to move on to the next step and automate most of their
forms. some are boilerplate forms that are simple printed without change.
some are boilerplate but require signatures from client and rep. Others
provide for entry of quite a bit of data.

All forms will be filed manually in hardcopy (yes I am trying to bring
them into the 20th century, but then they quote Federal Goverment
requirements... ). Some of the data from the forms will need to preferably
be populated from the database, name, phone, etc. Some forms will have a
few fields recorded to the database as well as the form. Some forms will
have many fields recorded to the database.

Obviously it would be desirable to keep the completed forms accessible
electronically (and hopefully the long term repository once we get rid of
all the paper files).

Anyone have suggestions for software that have used for something similar
with good success?

The client is a nonprofit so price is a factor.

Just about any information that you can capture on a paper form, you can
capture on an Access Form -- and Access has the capability to create Forms,
so I can't guess why anyone would need "forms software to integrate with
Access." Presumably, the forms in question would be specific to a particular
user organization, or industry, or sector, or ??? and would have to be
"custom forms" even if you used some "forms software."

The exceptions to "easy capture" are hand-drawn diagrams and handwriting.

I've seen one application that used the user's USERID to look up and insert
a filed signature image (the network login ID could also be used, or the
user required to enter name/password), and others that used various forms of
electronic signature validation. Whatever the "authority" requiring the
signatures has specified would determine the approach you could use -- and,
if storing a paper copy is required, it may be that a physical signature on
that paper copy is what's needed.

Larry Linson
Microsoft Access MVP

[bobalston]

Larry Linson wrote:

"Bob Alston" wrote

I am looking for electronic forms software
that would integrate well with MS Access.

I have a client for whom I built a client database to replace and update
one they had that was obsolete and not doing what they want.
They are wanting to move on to the next step and automate most of their
forms. some are boilerplate forms that are simple printed without change.
some are boilerplate but require signatures from client and rep. Others
provide for entry of quite a bit of data.

All forms will be filed manually in hardcopy (yes I am trying to bring
them into the 20th century, but then they quote Federal Goverment
requirements... ). Some of the data from the forms will need to preferably
be populated from the database, name, phone, etc. Some forms will have a
few fields recorded to the database as well as the form. Some forms will
have many fields recorded to the database.

Obviously it would be desirable to keep the completed forms accessible
electronically (and hopefully the long term repository once we get rid of
all the paper files).

Anyone have suggestions for software that have used for something similar
with good success?

The client is a nonprofit so price is a factor.

Just about any information that you can capture on a paper form, you can
capture on an Access Form -- and Access has the capability to create Forms,
so I can't guess why anyone would need "forms software to integrate with
Access." Presumably, the forms in question would be specific to a particular
user organization, or industry, or sector, or ??? and would have to be
"custom forms" even if you used some "forms software."

The exceptions to "easy capture" are hand-drawn diagrams and handwriting.

I've seen one application that used the user's USERID to look up and insert
a filed signature image (the network login ID could also be used, or the
user required to enter name/password), and others that used various forms of
electronic signature validation. Whatever the "authority" requiring the
signatures has specified would determine the approach you could use -- and,
if storing a paper copy is required, it may be that a physical signature on
that paper copy is what's needed.

Larry Linson
Microsoft Access MVP

Thanks for the reply. I'm just looking for something that would be
simpler to convert the existing forms to electronic format. Also I
think only a small portion of the date entered into the forms will need
to go into the Access database.

And yes I could build everything with Access Forms capabilities. But
in this case, I am hoping there is an easier solution.

Bob

[Larry Linson]

<bo*******@gmai l.comwrote

Thanks for the reply. I'm just looking
for something that would be simpler to
convert the existing forms to electronic
format. Also I think only a small portion
of the date entered into the forms will need
to go into the Access database.

And yes I could build everything with
Access Forms capabilities. But in this
case, I am hoping there is an easier solution.

All the Forms software I looked at was no easier than Access Forms, but all
of it provided less functionality. That was a few years ago, so the
"universe" of Forms software could have changed since then. I wish you
better luck.

Larry Linson

[Bob Alston]

bo*******@gmail .com wrote:

Larry Linson wrote:

>>"Bob Alston" wrote

I am looking for electronic forms software
that would integrate well with MS Access.

>>>I have a client for whom I built a client database to replace and update
one they had that was obsolete and not doing what they want.
They are wanting to move on to the next step and automate most of their
forms. some are boilerplate forms that are simple printed without change.
some are boilerplate but require signatures from client and rep. Others
provide for entry of quite a bit of data.

All forms will be filed manually in hardcopy (yes I am trying to bring
them into the 20th century, but then they quote Federal Goverment
requirements ...). Some of the data from the forms will need to preferably
be populated from the database, name, phone, etc. Some forms will have a
few fields recorded to the database as well as the form. Some forms will
have many fields recorded to the database.

Obviously it would be desirable to keep the completed forms accessible
electronical ly (and hopefully the long term repository once we get rid of
all the paper files).

Anyone have suggestions for software that have used for something similar
with good success?

The client is a nonprofit so price is a factor.

Just about any information that you can capture on a paper form, you can
capture on an Access Form -- and Access has the capability to create Forms,
so I can't guess why anyone would need "forms software to integrate with
Access." Presumably, the forms in question would be specific to a particular
user organization, or industry, or sector, or ??? and would have to be
"custom forms" even if you used some "forms software."

The exceptions to "easy capture" are hand-drawn diagrams and handwriting.

I've seen one application that used the user's USERID to look up and insert
a filed signature image (the network login ID could also be used, or the
user required to enter name/password), and others that used various forms of
electronic signature validation. Whatever the "authority" requiring the
signatures has specified would determine the approach you could use -- and,
if storing a paper copy is required, it may be that a physical signature on
that paper copy is what's needed.

Larry Linson
Microsoft Access MVP

Thanks for the reply. I'm just looking for something that would be
simpler to convert the existing forms to electronic format. Also I
think only a small portion of the date entered into the forms will need
to go into the Access database.

And yes I could build everything with Access Forms capabilities. But
in this case, I am hoping there is an easier solution.

Bob

OK I am now trying to find ways to do this with native Access forms.
I am still hoping to avoid setting up individual text boxes for all the
form instructions and boilerplate content.

Here is a link to a sample goverment defined form:

http://www.ltca.org/ADvantage/Documents/ADv5.pdf

and

http://www.ltca.org/ADvantage/Documents/ADv6a1b.pdf

I noticed that some of the forms packages, took an image of the pager
form and then allowed you to draw data fields on top of that. I got a
PDF version of the goverment mandated forms. Converted to JPG at high
resolution (Used 300 resolution when converting PDF to JPG). Created a
large image in an Access form and set the source as the JPG file. On
the screen the characters are not crisp but when printed the quality is
fine. Used 300 resolution when converting PDF to JPG.

And yes I can create fields that have transparent backgrounds and define
the fields where I want data entered.

Anyone done this before? Any tips and tricks?

Right now it appears I may need to slightly trim the JPG file to avoid
page overflow.

Should I use a format other than JPG?

Other suggestions?

Thanks

Bob

[David W. Fenton]

Bob Alston <bo********@yah oo.comwrote in
news:5k******** *********@fe05. lga:

Should I use a format other than JPG?

Definitely.

Use a bitmap, as the JPG is converted to a bitmap before
storing, so you end up storing both the JPG and the bitmap, when all
you need is the bitmap.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Bob Alston]

David W. Fenton wrote:

Bob Alston <bo********@yah oo.comwrote in
news:5k******** *********@fe05. lga:

>>Should I use a format other than JPG?

Definitely.

Use a bitmap, as the JPG is converted to a bitmap before
storing, so you end up storing both the JPG and the bitmap, when all
you need is the bitmap.

Thanks. I just noticed that using a JPG for the image results in the
same kind of 50 meg overhead in the database that addition of JPG images
in a Jet database does.

Bob

[Bob Alston]

Bob Alston wrote:

David W. Fenton wrote:

>Bob Alston <bo********@yah oo.comwrote in
news:5k******* **********@fe05 .lga:

>>Should I use a format other than JPG?

Definitely.
Use a bitmap, as the JPG is converted to a bitmap before
storing, so you end up storing both the JPG and the bitmap, when all
you need is the bitmap.

Thanks. I just noticed that using a JPG for the image results in the
same kind of 50 meg overhead in the database that addition of JPG images
in a Jet database does.

Bob

Another question. Should I define the bitmapped image in the form
definition or use the approach to load the bitmap from a file at run
time into the blog control at run time, as is suggested for handling
pictures in databases to avoid the "OLE overhead"?

Bob

[David W. Fenton]

Bob Alston <bo********@yah oo.comwrote in
news:k%******** *****@fe03.lga:

Another question. Should I define the bitmapped image in the form
definition or use the approach to load the bitmap from a file at
run time into the blog control at run time, as is suggested for
handling pictures in databases to avoid the "OLE overhead"?

It depends. If you load it from disk, it will be slower, but won't
bloat the database. But then you also end up with more files needed
to run your app. I generally go with embedding in the form, since I
don't see any point in worrying about bloat of this kind.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"Bob Alston" <bo********@yah oo.comwrote

Converted to JPG at high resolution (Used
300 resolution when converting PDF to JPG).
Created a large image in an Access form and
set the source as the JPG file. On the screen
the characters are not crisp but when printed
the quality is fine. Used 300 resolution when
converting PDF to JPG.

And yes I can create fields that have transparent
backgrounds and define the fields where I
want data entered.

Anyone done this before? Any tips and tricks?

I scanned in "official" forms for a prototype application back in Access 1.1
or 2.0 days, to use as background for a report. Images required just as
much processing then, as now, but my processor was only 33MHz. <SIGHIt
took approximately forever to do anything with the report once I'd embedded
the image. So I started over without the image, created the Controls first,
tried to use a printed copy with a copy of the form held up to the light to
locate them as closely as I could, then embedded the image, and suffered
through the slowness on the final tweaking. Fortunately, with today's
processors running at 3.x GHz, and much faster graphics cards, you are
unlikely to face similar problems.

Turns out I hadn't properly "qualified" the client (who'd sought me out at a
user group meeting) and he had expected custom software at shrinkwrap
prices, so it was all for naught, anyway. I wrote off the cost of scanning
(scanners were pretty expensive back then, so I paid someone to scan the
forms) as a marketing expense.

Should I use a format other than JPG?

David already answered this one, and answered it very well indeed.

Larry Linson
Microsoft Access MVP