why use visual basic?

Re: why use visual basic?


"glm" <gmidonnet@hotm ail.com> wrote in message
news:b4b43d4.03 12302024.683ba2 [email protected] le.com...[color=blue]
> I'm a web developer (cold fusion, php, access, mySQL). A client would
> like for me to build a windows based app for him. I have suggested
> that he keep it web-based but he insists that it be available on
> unconnected desktops. (It is catalogue of items. Selecting an item
> will display information regarding that item. -- It does get fairly
> involved but that is the essence of project.)
>
> -- The app will need to tie into a database. Access would do, about
> 20-30 tables, under 500,000 records. Users will not update the
> database.
>
> -- It would be loaded into a variety of stand-alone desktops.
>[/color]
[color=blue]
> -- It would have to be secure. Employees should not be able to readily
> download the data. (Yes screenshots could do it).
>
> He's even thinking about selling the catalogue to customers.
>
> I'm wondering if VB is the way to go.
>
> It may be beyond me but I would like to give it a shot.
>
> thanks for any input,
>
> -- gil[/color]

Even though this a VB group, and I'm a VB programmer, I would say don't
do it in VB/Acess. For a read only app, there is no reason to hassle
with MDAC, ADO, etc.

Not being Web based doesn't mean you can't use HTML. Most help files
these days are HTML, for instance. You can stick an entire web site on a
CD-ROM, point the user to the home page, and off they go, as long as all
the links are relative ones.

You wouldn't have a web server to do any script processing, but you can
do some stuff within the HTML itself. It might only work with Internet
Explorer, but so what? You might even be able to setup all the data as
XML, and then have a few simple scripts to do the browsing and
selecting.

I can't say I know all the details, or what it would actually take to
make it all work, but that is the direction I would look.

Re: why use visual basic?


VB is great for database access, but I can't see why the access
couldn't, or even shouldn't be done through a browser. As you know,
local files display just dandy through a browser. In fact, it's getting
quite common to see programs install local help files that are viewed
and searched through the browser. Going this route leaves you a *ton* of
flexibility down the road. I'm in the process of dealing with these very
issues actually. Our business web site is running an online catalog that
is displayed and searched via compiled executable CGI's... written in
VB, of course. ;-) Compiled executables smoke scripted languages on
speed, big time. Our internal software pulls much of it's data from the
same database as the web site and I'd built a Windows based app to TCB
in-house, but I'm in the process of rewriting that to be done through
the browser with VB CGI's. It opens a ton of possibilities down the
road. For starters, our sales reps can place orders directly into the
system instantly or tell the customer literally anything that anyone in
our office could via their laptop/cell phone while sitting right in the
customers office. :-) As far as security goes, while there will be
extensive authentication much of the worry is removed by simply limiting
access to server on which the CGI's involved with in-house functions
reside on to internal LAN IPs and making all external access to those
in-house functions through our RAS server. Basically, the only way into
the in-house functions is to dial straight into our LAN and
authenticate. The in-house stuff *can't* be accessed by the WAN, period.
Problem solved, pretty much. :-)

Anyway, while I don't know all of the circumstances, it looks from here
like your client may be unnecessarily limiting his options IMO.


glm wrote:[color=blue]
> I'm a web developer (cold fusion, php, access, mySQL). A client would
> like for me to build a windows based app for him. I have suggested
> that he keep it web-based but he insists that it be available on
> unconnected desktops. (It is catalogue of items. Selecting an item
> will display information regarding that item. -- It does get fairly
> involved but that is the essence of project.)
>
> -- The app will need to tie into a database. Access would do, about
> 20-30 tables, under 500,000 records. Users will not update the
> database.
>
> -- It would be loaded into a variety of stand-alone desktops.
>
> -- It would have to be secure. Employees should not be able to readily
> download the data. (Yes screenshots could do it).
>
> He's even thinking about selling the catalogue to customers.
>
> I'm wondering if VB is the way to go.
>
> It may be beyond me but I would like to give it a shot.
>
> thanks for any input,
>
> -- gil[/color]

Re: why use visual basic?

What if you put an apche WAMPP version on a standalone pc with the compleete
website in the htacces folder? No rewriting, just copy the site and it will
work localy.
XWAMMP comes to mind as a very fine one. You only need to think of a trick
to start running the MySQL and The apache enigne without user interference.

And as XAMMP does not require real installation (as in editing the registry
and stuff) it should be able to run straigt from the cd...


"glm" <gmidonnet@hotm ail.com> schreef in bericht
news:b4b43d4.03 12302024.683ba2 [email protected] le.com...[color=blue]
> I'm a web developer (cold fusion, php, access, mySQL). A client would
> like for me to build a windows based app for him. I have suggested
> that he keep it web-based but he insists that it be available on
> unconnected desktops. (It is catalogue of items. Selecting an item
> will display information regarding that item. -- It does get fairly
> involved but that is the essence of project.)
>
> -- The app will need to tie into a database. Access would do, about
> 20-30 tables, under 500,000 records. Users will not update the
> database.
>
> -- It would be loaded into a variety of stand-alone desktops.
>
> -- It would have to be secure. Employees should not be able to readily
> download the data. (Yes screenshots could do it).
>
> He's even thinking about selling the catalogue to customers.
>
> I'm wondering if VB is the way to go.
>
> It may be beyond me but I would like to give it a shot.
>
> thanks for any input,
>
> -- gil[/color]

Re: why use visual basic?

On 30 Dec 2003 20:24:57 -0800, gmidonnet@hotma il.com (glm) wrote:
[color=blue]
>I'm a web developer (cold fusion, php, access, mySQL). A client would
>like for me to build a windows based app for him. I have suggested
>that he keep it web-based but he insists that it be available on
>unconnected desktops. (It is catalogue of items. Selecting an item
>will display information regarding that item. -- It does get fairly
>involved but that is the essence of project.)[/color]

<snip>

This sounds like a classic CD Application

Not especially difficult, but if you are not a VB programmer ...

You could alternatively take a look at something like LIKSE



It would probably do what you want

Although it is possible that your client will want to encrypt the data
- in which case a Google search should pull up a few products

Another method is to use the THTML Browser from Dave Baldwin


and code the system in Delphi - that is the route I took

Re: why use visual basic?

> Not being Web based doesn't mean you can't use HTML. Most help files[color=blue]
> these days are HTML, for instance. You can stick an entire web site on a
> CD-ROM, point the user to the home page, and off they go, as long as all
> the links are relative ones.[/color]
[color=blue]
> You wouldn't have a web server to do any script processing, but you can
> do some stuff within the HTML itself. It might only work with Internet
> Explorer, but so what? You might even be able to setup all the data as
> XML, and then have a few simple scripts to do the browsing and
> selecting.[/color]

Thanks everybody for your great responses, but I'm still confused.

I must be missing something -- or perhaps I haven't given enough
information.

This should be a stand alone app, ie:
-- neither IIS nor apache should have to be installed on the computer;
-- and for security reasons the db should not be in an easily
accessable file where employees could just download it.

I can write all the help files in HTML, but the data has to be pulled
into the display files via: Cold Fusion, PHP, ASP. Each of these
requires IIS or apache.

I must be missing something here.

thx, gil

Re: why use visual basic?

gmidonnet@hotma il.com (glm) wrote in message news:<b4b43d4.0 312310720.43a7c [email protected] gle.com>...[color=blue][color=green]
> > Not being Web based doesn't mean you can't use HTML. Most help files
> > these days are HTML, for instance. You can stick an entire web site on a
> > CD-ROM, point the user to the home page, and off they go, as long as all
> > the links are relative ones.[/color]
>[color=green]
> > You wouldn't have a web server to do any script processing, but you can
> > do some stuff within the HTML itself. It might only work with Internet
> > Explorer, but so what? You might even be able to setup all the data as
> > XML, and then have a few simple scripts to do the browsing and
> > selecting.[/color]
>
> Thanks everybody for your great responses, but I'm still confused.
>
> I must be missing something -- or perhaps I haven't given enough
> information.
>
> This should be a stand alone app, ie:
> -- neither IIS nor apache should have to be installed on the computer;
> -- and for security reasons the db should not be in an easily
> accessable file where employees could just download it.
>
> I can write all the help files in HTML, but the data has to be pulled
> into the display files via: Cold Fusion, PHP, ASP. Each of these
> requires IIS or apache.[/color]

Assuming you have an HTML document with embedded client-side scripting
to access a DLL or OCX installed on the client then you do not need
any of the things you mention. The DLL/OCX can read a local database
(Acess, MSDE, or any other format including a proprietary one) to get
the data and have it displayed on the HTML page.

Since one of your requirements is that it run disconnected you
essentially have to design for that first. That means a local copy of
the data which may be in an obscure format and/or encrypted somehow to
prevent use outside your application but somehow you have to be able
to manipulate the data with no network connections. The second thing
to figure out is how best to update the local data (either offline by
CD/DVD/diskette/etc or online when connected). Finally, when
connected to the network you have 2 options: use the local copy or
read the most recent data off the server. You can make that dynamic
or have the app update local data periodically when connected and then
always use the local copy. The best approach may depend on how
volatile the data is and how bad it is for a user to be seeing
outdated information.

Re: why use visual basic?

RE/[color=blue]
>This sounds like a classic CD Application
>
>Not especially difficult, but if you are not a VB programmer ...
>
>You could alternatively take a look at something like LIKSE[/color]

I've done a couple of CD-based apps using MS Access 2.0. Depending on how
simple the interface is, that could be a viable option. Extremely-rapid
development time. Access 2.0 is "dead" in most people's minds, but you can
have a runtime version installed just by copying less than 20 .DLLs - and no
registration considerations. ..just copy them into the same dir as the app and
go.
--
PeteCresswell

Re: why use visual basic?

On Wed, 31 Dec 2003 23:39:08 GMT, "(Pete Cresswell)" <[email protected]> wrote:
[color=blue]
>RE/[color=green]
>>This sounds like a classic CD Application
>>
>>Not especially difficult, but if you are not a VB programmer ...
>>
>>You could alternatively take a look at something like LIKSE[/color]
>
>I've done a couple of CD-based apps using MS Access 2.0. Depending on how
>simple the interface is, that could be a viable option. Extremely-rapid
>development time. Access 2.0 is "dead" in most people's minds, but you can
>have a runtime version installed just by copying less than 20 .DLLs - and no
>registration considerations. ..just copy them into the same dir as the app and
>go.[/color]

Hmm ... I've got it down to zero installation

But I am an old git that likes using his own filing systems

Re: why use visual basic?

thx everyone again.

[color=blue]
> Assuming you have an HTML document with embedded client-side scripting
> to access a DLL or OCX installed on the client then you do not need
> any of the things you mention. The DLL/OCX can read a local database
> (Acess, MSDE, or any other format including a proprietary one) to get
> the data and have it displayed on the HTML page.[/color]

I'll have to look into this.


Regarding the data. It gets updated every 6 months and CDs with the
updated information would be sent to the stores and the customers.

I'm still a little confused but I guess its time that I start learning
a bit about windows based apps.

For example I understand the security involved for a web-based system
but if something is installed on a local computer I thought the data
and the delivery mechanism had to be contained within an app.

Have a great new year. I'll write again when I understand the process
better.

-- gil