469,288 Members | 2,353 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,288 developers. It's quick & easy.

why use visual basic?

glm
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
Jul 17 '05 #1
9 6706

"glm" <gm*******@hotmail.com> wrote in message
news:b4*************************@posting.google.co m...
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


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.
Jul 17 '05 #2
Me

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:
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


Jul 17 '05 #3
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" <gm*******@hotmail.com> schreef in bericht
news:b4*************************@posting.google.co m...
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

Jul 17 '05 #4
On 30 Dec 2003 20:24:57 -0800, gm*******@hotmail.com (glm) wrote:
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.)


<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

http://www.faico.net/likse/index.html

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
www.PBear.com

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

Jul 17 '05 #5
glm
> 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.


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
Jul 17 '05 #6
gm*******@hotmail.com (glm) wrote in message news:<b4*************************@posting.google.c om>...
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.


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.


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.
Jul 17 '05 #7
RE/
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


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
Jul 17 '05 #8
On Wed, 31 Dec 2003 23:39:08 GMT, "(Pete Cresswell)" <x@y.z> wrote:
RE/
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


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.


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

But I am an old git that likes using his own filing systems
Jul 17 '05 #9
glm
thx everyone again.

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.


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
Jul 17 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by pix | last post: by
2 posts views Thread by frossberg | last post: by
97 posts views Thread by Master Programmer | last post: by
11 posts views Thread by =?Utf-8?B?UGV0ZXI=?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.