Recordkeeping

I have a project to put together. My company keeps records of employee
regulatory testing. I want to put together a program that will track
employee testing.

The employee will log in, take the test which, only whether they passed or
failed the test, will need to be stored in the database. There will also be
an interface that will show them what tests they have passed/failed and
which ones haven't been taken. From there, they should be able to click on a
link to take another test. I have some programming experience, I'm just not
sure what would be the best way for this information to flow (ASP, Access,
VB, SQL, XML, etc.).

I would like to start out with something small (2 or 3 users and only a
couple of tests).

Any help would be appreciated,

Jerry

If this is a company-wide project, the easiest way would probably be a
web-based product (but read further for more info). You could use Access/Jet
to store this information, but your company's intranet may already host a
database engine like MySQL, Oracle, MSSQL etc. And Access is file-based,
thus while it's often easier for you to work with, it's also easier to hack
than server-based data. I don't know how sensitive this information would
be, but if it's something that could cause legal problems if it leaks out,
you might want to use a more secure database engine like metioned earlier.

If you go web-based, the language you'd use would depend on what type of
server it's hosted on. If it's a Windows machine, then your best bet is ASP
(or ASP.NET, depending on your flavor of servers) to render dynamic pages,
and ADO to "talk" to the database. You'd use Structured Query Langauge (SQL)
from within ADO to retrieve/update data ...

Of course, you could also write a VB/Access frontend that connects to your
server database, if that's more to your liking. Desktop applications are
usually much more feature rich than web-based ones, thus you can do a lot
more with a desktop application. The trouble with this type of scenario is
updates and deployment hassles. When you need to send out a new frontend,
you'll have to update all users individually. You can automate this any
number of ways, of course, but it's still a problem to deal with. There's
also the issue of compatibilty among desktop environments (especially if you
use Access as the frontend); different combinations of OS/Office can cause
headaches. Again, this isn't insurmountable, but it's one factor to
consider.

What it boils down to is this: a web-based interface is easier to deploy and
maintain that a desktop interface. However, a desktop interface offers you
many more User Interface considerations than does a web-based. So you must
determine which are the more important aspects. If your tests are all yes/no
or simple multiple choice, then a web-based interface would work fine. If
users must manipulate objects (i.e move things around on screen) or draw
things, a desktop environment will be much more useful.


"Jerry W. Swatsell" <swatsell@swbell.net> wrote in message
news:I3S1e.3682$oy3.485@newssvr30.news.prodigy.com ...[color=blue]
>I have a project to put together. My company keeps records of employee
> regulatory testing. I want to put together a program that will track
> employee testing.
>
> The employee will log in, take the test which, only whether they passed or
> failed the test, will need to be stored in the database. There will also
> be
> an interface that will show them what tests they have passed/failed and
> which ones haven't been taken. From there, they should be able to click on
> a
> link to take another test. I have some programming experience, I'm just
> not
> sure what would be the best way for this information to flow (ASP, Access,
> VB, SQL, XML, etc.).
>
> I would like to start out with something small (2 or 3 users and only a
> couple of tests).
>
> Any help would be appreciated,
>
> Jerry
>
>
>[/color]

Scott,
Java and C# and VB.NET and similar things offer enough widgets that you can
do quite a bit to design a UI that doesn't feel like a warmed over web page.
I'd make the case that a web-based project can be well-designed and easy to
use. The effort to do the requirements isn't that much greater and the
lifespan of a web-based application is likely to be better/cheaper than
committing to a version of Office/Access. I am generally agin Access
anyway, a search of Google will pull up plenty of my posts that show this,
so given the option I'd pick an IDE like Eclipse, an OpenSource rdbms like
PostgreSQL and Java as my toolkit. If it's a Microsoft house then C#,
VB.Net and SQL Server or MSDE are my prefferred choices over Jet/Access &
VBA.

"Scott McDaniel" <scott@NO_SPAM_HEREthedatabaseplace.net> wrote in message
news:zfCdnYMrWNYSZdrfRVn-iA@comcast.com...[color=blue]
> If this is a company-wide project, the easiest way would probably be a
> web-based product (but read further for more info). You could use
> Access/Jet to store this information, but your company's intranet may
> already host a database engine like MySQL, Oracle, MSSQL etc. And Access
> is file-based, thus while it's often easier for you to work with, it's
> also easier to hack than server-based data. I don't know how sensitive
> this information would be, but if it's something that could cause legal
> problems if it leaks out, you might want to use a more secure database
> engine like metioned earlier.
>
> If you go web-based, the language you'd use would depend on what type of
> server it's hosted on. If it's a Windows machine, then your best bet is
> ASP (or ASP.NET, depending on your flavor of servers) to render dynamic
> pages, and ADO to "talk" to the database. You'd use Structured Query
> Langauge (SQL) from within ADO to retrieve/update data ...
>
> Of course, you could also write a VB/Access frontend that connects to your
> server database, if that's more to your liking. Desktop applications are
> usually much more feature rich than web-based ones, thus you can do a lot
> more with a desktop application. The trouble with this type of scenario is
> updates and deployment hassles. When you need to send out a new frontend,
> you'll have to update all users individually. You can automate this any
> number of ways, of course, but it's still a problem to deal with. There's
> also the issue of compatibilty among desktop environments (especially if
> you use Access as the frontend); different combinations of OS/Office can
> cause headaches. Again, this isn't insurmountable, but it's one factor to
> consider.
>
> What it boils down to is this: a web-based interface is easier to deploy
> and maintain that a desktop interface. However, a desktop interface offers
> you many more User Interface considerations than does a web-based. So you
> must determine which are the more important aspects. If your tests are all
> yes/no or simple multiple choice, then a web-based interface would work
> fine. If users must manipulate objects (i.e move things around on screen)
> or draw things, a desktop environment will be much more useful.
>
>
> "Jerry W. Swatsell" <swatsell@swbell.net> wrote in message
> news:I3S1e.3682$oy3.485@newssvr30.news.prodigy.com ...[color=green]
>>I have a project to put together. My company keeps records of employee
>> regulatory testing. I want to put together a program that will track
>> employee testing.
>>
>> The employee will log in, take the test which, only whether they passed
>> or
>> failed the test, will need to be stored in the database. There will also
>> be
>> an interface that will show them what tests they have passed/failed and
>> which ones haven't been taken. From there, they should be able to click
>> on a
>> link to take another test. I have some programming experience, I'm just
>> not
>> sure what would be the best way for this information to flow (ASP,
>> Access,
>> VB, SQL, XML, etc.).
>>
>> I would like to start out with something small (2 or 3 users and only a
>> couple of tests).
>>
>> Any help would be appreciated,
>>
>> Jerry
>>
>>
>>[/color]
>
>[/color]

I really appreciate your input. I think I may end up outsourcing. I think I
may be in a little over my head :)

"Alan Webb" <knogeek@hotmail.com> wrote in message
news:e5Gdna6Mtfh7htXfRVn-qA@comcast.com...[color=blue]
> Scott,
> Java and C# and VB.NET and similar things offer enough widgets that you
> can do quite a bit to design a UI that doesn't feel like a warmed over web
> page. I'd make the case that a web-based project can be well-designed and
> easy to use. The effort to do the requirements isn't that much greater
> and the lifespan of a web-based application is likely to be better/cheaper
> than committing to a version of Office/Access. I am generally agin Access
> anyway, a search of Google will pull up plenty of my posts that show this,
> so given the option I'd pick an IDE like Eclipse, an OpenSource rdbms like
> PostgreSQL and Java as my toolkit. If it's a Microsoft house then C#,
> VB.Net and SQL Server or MSDE are my prefferred choices over Jet/Access &
> VBA.
>
> "Scott McDaniel" <scott@NO_SPAM_HEREthedatabaseplace.net> wrote in message
> news:zfCdnYMrWNYSZdrfRVn-iA@comcast.com...[color=green]
>> If this is a company-wide project, the easiest way would probably be a
>> web-based product (but read further for more info). You could use
>> Access/Jet to store this information, but your company's intranet may
>> already host a database engine like MySQL, Oracle, MSSQL etc. And Access
>> is file-based, thus while it's often easier for you to work with, it's
>> also easier to hack than server-based data. I don't know how sensitive
>> this information would be, but if it's something that could cause legal
>> problems if it leaks out, you might want to use a more secure database
>> engine like metioned earlier.
>>
>> If you go web-based, the language you'd use would depend on what type of
>> server it's hosted on. If it's a Windows machine, then your best bet is
>> ASP (or ASP.NET, depending on your flavor of servers) to render dynamic
>> pages, and ADO to "talk" to the database. You'd use Structured Query
>> Langauge (SQL) from within ADO to retrieve/update data ...
>>
>> Of course, you could also write a VB/Access frontend that connects to
>> your server database, if that's more to your liking. Desktop applications
>> are usually much more feature rich than web-based ones, thus you can do a
>> lot more with a desktop application. The trouble with this type of
>> scenario is updates and deployment hassles. When you need to send out a
>> new frontend, you'll have to update all users individually. You can
>> automate this any number of ways, of course, but it's still a problem to
>> deal with. There's also the issue of compatibilty among desktop
>> environments (especially if you use Access as the frontend); different
>> combinations of OS/Office can cause headaches. Again, this isn't
>> insurmountable, but it's one factor to consider.
>>
>> What it boils down to is this: a web-based interface is easier to deploy
>> and maintain that a desktop interface. However, a desktop interface
>> offers you many more User Interface considerations than does a web-based.
>> So you must determine which are the more important aspects. If your tests
>> are all yes/no or simple multiple choice, then a web-based interface
>> would work fine. If users must manipulate objects (i.e move things around
>> on screen) or draw things, a desktop environment will be much more
>> useful.
>>
>>
>> "Jerry W. Swatsell" <swatsell@swbell.net> wrote in message
>> news:I3S1e.3682$oy3.485@newssvr30.news.prodigy.com ...[color=darkred]
>>>I have a project to put together. My company keeps records of employee
>>> regulatory testing. I want to put together a program that will track
>>> employee testing.
>>>
>>> The employee will log in, take the test which, only whether they passed
>>> or
>>> failed the test, will need to be stored in the database. There will also
>>> be
>>> an interface that will show them what tests they have passed/failed and
>>> which ones haven't been taken. From there, they should be able to click
>>> on a
>>> link to take another test. I have some programming experience, I'm just
>>> not
>>> sure what would be the best way for this information to flow (ASP,
>>> Access,
>>> VB, SQL, XML, etc.).
>>>
>>> I would like to start out with something small (2 or 3 users and only a
>>> couple of tests).
>>>
>>> Any help would be appreciated,
>>>
>>> Jerry
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]