Access v dot net

[Deano]

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to replicate
a existing Access app?
I would be interested to hear how any stories about this and in particular
how one deals with not having subforms - can you get a third-party control
to fill that gap?

[Lyle Fairfield]

"Deano" <de***@mailinator.com> wrote in
news:44**********************@ptn-nntp-reader01.plus.net:

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to
replicate a existing Access app?
I would be interested to hear how any stories about this and in
particular how one deals with not having subforms - can you get a
third-party control to fill that gap?

What gap? Subforms are nothing except forms contained in a control. Linking
to one's own form that mimics a subform can be done very easily with code.
If one can create one graphical interface using .net then certainly can
create another, analagous to the sub-form.

--
Lyle Fairfield

[Deano]

Lyle Fairfield wrote:

"Deano" <de***@mailinator.com> wrote in
news:44**********************@ptn-nntp-reader01.plus.net:

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to
replicate a existing Access app?
I would be interested to hear how any stories about this and in
particular how one deals with not having subforms - can you get a
third-party control to fill that gap?

What gap? Subforms are nothing except forms contained in a control.
Linking to one's own form that mimics a subform can be done very
easily with code. If one can create one graphical interface using
.net then certainly can create another, analagous to the sub-form.

Thanks, food for thought. I might see what I can get accomplished using C#
Express.

[Jerry Boone]

This depends on what you are doing, how many people you are deploying to,
and how much patience you have. Oh yeah, and what kind of budget/timeline
you are working in.

I picked up VB.Net a few years ago, built several web apps, decent small
accounting app, and some other utilities. I like it, but it has a big
learning curve over Access or even VB6 and it's predecessors. I hate to
write this, but it took 6 months to become anywhere near proficient -
especially in developing the first web app.

There are still a lot of apps I would write in VB6 to get a performance
advantage with today's processors. It starts fast and gets with it. And...
if I was a C junky... well of course I would do it in C++. You see, there
really isn't much advantage to go C#.NET over VB.NET. The CLR treats them
pretty darn fairly - it's simply a matter of preference. Also, if you are
writing proprietary code and sending it to market... make sure you get into
obfuscation (scrambles source code that get's deployed to the client GAC).

I would stay with Access if your users would have a big advantage using the
built in filtering, sorting, datasheet views, and all of that because it's
fairly time consuming to re-create all that stuff in another development
environment.

You can use a variety of grid controls to make use of subform replacement.
Expect to spend around $500 for these components, I personally think
Infragistics has it together with their NetAdvantage line.

--
Jerry Boone
"Deano" <de***@mailinator.com> wrote in message
news:44**********************@ptn-nntp-reader01.plus.net...

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to replicate a existing Access app?
I would be interested to hear how any stories about this and in particular
how one deals with not having subforms - can you get a third-party control
to fill that gap?

[Deano]

Jerry Boone wrote:

This depends on what you are doing, how many people you are deploying
to, and how much patience you have. Oh yeah, and what kind of
budget/timeline you are working in.

I picked up VB.Net a few years ago, built several web apps, decent
small accounting app, and some other utilities. I like it, but it
has a big learning curve over Access or even VB6 and it's
predecessors. I hate to write this, but it took 6 months to become
anywhere near proficient - especially in developing the first web app.

There are still a lot of apps I would write in VB6 to get a
performance advantage with today's processors. It starts fast and
gets with it. And... if I was a C junky... well of course I would do
it in C++. You see, there really isn't much advantage to go C#.NET
over VB.NET. The CLR treats them pretty darn fairly - it's simply a
matter of preference. Also, if you are writing proprietary code and
sending it to market... make sure you get into obfuscation (scrambles
source code that get's deployed to the client GAC).

I would stay with Access if your users would have a big advantage
using the built in filtering, sorting, datasheet views, and all of
that because it's fairly time consuming to re-create all that stuff
in another development environment.

You can use a variety of grid controls to make use of subform
replacement. Expect to spend around $500 for these components, I
personally think Infragistics has it together with their NetAdvantage
line.
"Deano" <de***@mailinator.com> wrote in message
news:44**********************@ptn-nntp-reader01.plus.net...

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to
replicate a existing Access app?
I would be interested to hear how any stories about this and in
particular how one deals with not having subforms - can you get a
third-party control to fill that gap?

Thanks Jerry, great post. I was just thinking about expanding my knowledge
really. I'm ok in Access but a bit bored of it and want to try something
else.

[Jerry Boone]

I understand the feeling - it's good to get out and take a walk now and
then.

Do you have an application in mind? I might offer suggestion based on that
if you would rather.

--
Jerry Boone

[rkc]

Deano wrote:

Thanks Jerry, great post. I was just thinking about expanding my knowledge
really. I'm ok in Access but a bit bored of it and want to try something
else.

Try duplicating the last non-trivial application you built with Access
using C#. Let us know how it goes. Half the battle is recognizing just
what it is that Access does to make things so easy. Your question on
how to replace subforms is exhibit #1 in support of that.

[Deano]

rkc wrote:

Deano wrote:

Thanks Jerry, great post. I was just thinking about expanding my
knowledge really. I'm ok in Access but a bit bored of it and want
to try something else.

Try duplicating the last non-trivial application you built with Access
using C#. Let us know how it goes. Half the battle is recognizing just
what it is that Access does to make things so easy. Your question on
how to replace subforms is exhibit #1 in support of that.

Yes, I do realise that Access forms and reports are rather neat. But I do
want to do more than just work in VBA. If anything it should be
educational.

[Deano]

Jerry Boone wrote:

I understand the feeling - it's good to get out and take a walk now
and then.

Do you have an application in mind? I might offer suggestion based
on that if you would rather.

I have two apps in mind. My main one is the salary programme which is
heavily dependent on subforms. Each employee is a parent record while in
the first subform I have a related table which contains salary data.
Each row is a point on the salary range and there are checkboxes for each
month of the day. So say you could have 10 rows x 12 months, so you have
this grid of checkboxes with salary values on the left and a total column on
the right. The user can select up to 12 boxes, one for each month. I put
the subform in a tab control to save space and use another subform to show
the figures.

Now I know from some previous research that you can do a parent/detail setup
in .NET but I like the way that Access presents this info, i.e being able to
drop subform in that I can link to the main form very quickly. The .NET
example I saw meant you show the main records then click a button and the
form with the related tables would popup. In my app that would not work
from the user's point of view.

There isn't much reason to port this to .NET apart from the learning
experience which in itself would be valuable. But maybe it's also an
opportunity to add new features that I'm not even aware of right now, things
that aren't possible with Access.
The other app is my behaviour database which I've posted about here
previously. That's far more conventional and simple. The idea there is to
record details of behaviour incidents involving pupils. I'd also have to
keep track of their changing status (on report, special measures etc) and
other associated details. I think that would be a more likely candidate to
test out .NET.

[polite person]

On Mon, 03 Apr 2006 13:49:50 GMT, Lyle Fairfield <ly***********@aim.com> wrote:

"Deano" <de***@mailinator.com> wrote in
news:44**********************@ptn-nntp-reader01.plus.net:

Just looking at C Sharp to see if it might be worth my while learning
something new. Has anyone here tried a .NET language and tried to
replicate a existing Access app?
I would be interested to hear how any stories about this and in
particular how one deals with not having subforms - can you get a
third-party control to fill that gap?

What gap? Subforms are nothing except forms contained in a control. Linking
to one's own form that mimics a subform can be done very easily with code.
If one can create one graphical interface using .net then certainly can
create another, analagous to the sub-form.

It is the continuous forms feature rather than the subform per se which is the thing which is
particularly easy in Access, and harder in other situtions. (Grids are OK but more like datasheets
than continuous forms).

However I expect you already know this, as you seem to know everything else :)

[Jerry Boone]

In .NET you can do anything possible in Access... it's all a matter of how
much time you want (or can) invest.

The thing I think you need to grasp right away is that in .NET you will be
working with ADO.NET Datasets, DataTables, DataRows, and DataColumn objects.
It is natural to start off using the wizards, but remember (like any) these
wizards are going to create limitations that you would otherwise not
experience if you coded it all yourself. The wizard output is fairly decent
for study, but it's nothing you cannot write yourself and make a better fit
for your application.

I highly recommend ISBN 0-7356-1375-3 (Programming Visual Basic.NET by
Francesco Balena). It's 1500 pages of really great examples and one of the
most thorough books I have ever studied.

The example you used in .NET is definitely not showing you what you need to
see...

In your application you could query the employees into your main form (do a
wizard on this one if you want) then put a DataGrid (many flavors exist, the
grid provided in .NET is a good one to start with) onto the form. Code an
event that occurs when you click your <> on the datacontrol (similar to
oncurrent in access) to query the subform data you are accustomed to
retrieving. In this step you would use a connection, command, dataadapter,
and datatable (some may recommend using a dataset containing two datatables
and coded relationships)... then mygrid.databind the grid to the datatable
object. The grid will update the datatable for you under these
circumstances with little effort. You will probably want to do some
validation based on events that the grid will provide. Also, you will have
to design your grid using the property editor to get a checkbox column and
so on.

The thing to keep in mind is that this takes patience and persistence to
learn. It's really easy to just give up and go back to Access. Like I said
in a previous post, .NET has places in my development where I do not think
it is feasible.

Good luck, buy Francesco's book - it's probably the best tip I can offer.
This book mainly applies to 2002/2003 .NET so if you are going to use .NET
2005 you may want a different resource.

--
Jerry Boone
"Deano" <de***@mailinator.com> wrote in message
news:44**********************@ptn-nntp-reader01.plus.net...

Jerry Boone wrote:

I understand the feeling - it's good to get out and take a walk now
and then.

Do you have an application in mind? I might offer suggestion based
on that if you would rather.
I have two apps in mind. My main one is the salary programme which is
heavily dependent on subforms. Each employee is a parent record while in
the first subform I have a related table which contains salary data.
Each row is a point on the salary range and there are checkboxes for each
month of the day. So say you could have 10 rows x 12 months, so you have
this grid of checkboxes with salary values on the left and a total column

on the right. The user can select up to 12 boxes, one for each month. I put
the subform in a tab control to save space and use another subform to show
the figures.

Now I know from some previous research that you can do a parent/detail setup in .NET but I like the way that Access presents this info, i.e being able to drop subform in that I can link to the main form very quickly. The .NET
example I saw meant you show the main records then click a button and the
form with the related tables would popup. In my app that would not work
from the user's point of view.

There isn't much reason to port this to .NET apart from the learning
experience which in itself would be valuable. But maybe it's also an
opportunity to add new features that I'm not even aware of right now, things that aren't possible with Access.
The other app is my behaviour database which I've posted about here
previously. That's far more conventional and simple. The idea there is to record details of behaviour incidents involving pupils. I'd also have to
keep track of their changing status (on report, special measures etc) and
other associated details. I think that would be a more likely candidate to test out .NET.

[Lyle Fairfield]

"Jerry Boone" <je***@gomaps.com.nospam> wrote in
news:44**********************@news.hubris.net:

In .NET you can do anything possible in Access... it's all a matter of
how much time you want (or can) invest.

The thing I think you need to grasp right away is that in .NET you
will be working with ADO.NET Datasets, DataTables, DataRows, and
DataColumn objects.

I think that everyone needs to grasp that NET is not another flavour of COM
technology like Access, VB, Excel etc. It is an entirely new technology,
hence the requirement for the 123 megabyte NET framework on your machine
before you even begin to install and use any of the components of NET.

COM and NET are entirely different beasts. They work together with wrappers
and special technologies allowing them to communicate and cooperate. NET is
entirely new, as new for the developer as if one were going to learn to
program a Macintosh or a mini-computer, or a Base 3 device.

IMO MS has not been up front about this with the programmers and devlopers
who have used and supported its technologies for the last fifteen years. I
can find no place where it is clearly stated. Even the information about
the two disparate technolgies communicating is arcane. People here talk
about it as if it's another strain of VB. It's NOT. It's about as close to
VB, as reptiles are to mammals.

Get your head out of the sand. MS is deceiving you with its DataGrids and
Express Versions. This an entirely new alien technology.

It's time somebody said so.

--
Kyle Fairfield

[com]

On Thu, 6 Apr 2006 11:21:42 -0500, "Jerry Boone" <je***@gomaps.com.nospam> wrote (in part):

This book mainly applies to 2002/2003 .NET so if you are going to use .NET
2005 you may want a different resource.

If I program in the year 2022/23, will I have to get a different resource to program in the year
2205?

If so, I'll stay in the software industry, there will always be plenty of work!

[Larry Linson]

"com" <co*@com.com> wrote

This book mainly applies to 2002/2003 .NET so
if you are going to use .NET 2005 you may want
a different resource.

If I program in the year 2022/23, will I have to get a
different resource to program in the year 2205?

If so, I'll stay in the software industry, there will
always be plenty of work!

If there is "programming" in the year 2205, there is 100% probability that
the language/method used will be different from what is used in 2023. Eighty
years ago, "computers" were mechanical devices (or persons), not electronic
ones and there were no "programming languages" as we know them, though there
were plugboards that controlled the mechanical devices. I have known a good
many people who made the transition from plugboards to programming
languages. (Some of whom survive to this very day, but not a high
percentage.)

[com]

On Thu, 06 Apr 2006 19:48:54 GMT, "Larry Linson" <bo*****@localhost.not> wrote:

"com" <co*@com.com> wrote

This book mainly applies to 2002/2003 .NET so
if you are going to use .NET 2005 you may want
a different resource.

If I program in the year 2022/23, will I have to get a
different resource to program in the year 2205?

If so, I'll stay in the software industry, there will
always be plenty of work!

If there is "programming" in the year 2205, there is 100% probability that
the language/method used will be different from what is used in 2023. Eighty
years ago, "computers" were mechanical devices (or persons), not electronic
ones and there were no "programming languages" as we know them, though there
were plugboards that controlled the mechanical devices. I have known a good
many people who made the transition from plugboards to programming
languages. (Some of whom survive to this very day, but not a high
percentage.)

I'm afraid 2205 was a misprint for 2025, I was being sarcastic which isn't my metier

[Larry Linson]

Ok, "if you program in 2022 and 2023, will you have to get a new resource to
program in 2025?". It depends -- if some person or company has released a
startling, new technology that they can sell to your management/clients as
being more cost effective, more productive, etc., probably yes. If you were
a COBOL programmer asking that question a few years back, in retrospect, the
answer should have been "No." Because, now, as a generation of COBOL
programmers is retiring, the demand for COBOL talent is so great, that
various organizations are having to give their employees "crash courses" in
COBOL.

Larry Linson
Microsoft Access MVP
"com" <co*@com.com> wrote in message
news:sn********************************@4ax.com...

On Thu, 06 Apr 2006 19:48:54 GMT, "Larry Linson" <bo*****@localhost.not>
wrote:

"com" <co*@com.com> wrote

>> This book mainly applies to 2002/2003 .NET so
>> if you are going to use .NET 2005 you may want
>> a different resource.
>
> If I program in the year 2022/23, will I have to get a
>different resource to program in the year 2205?
>
> If so, I'll stay in the software industry, there will
> always be plenty of work!

If there is "programming" in the year 2205, there is 100% probability that
the language/method used will be different from what is used in 2023.
Eighty
years ago, "computers" were mechanical devices (or persons), not
electronic
ones and there were no "programming languages" as we know them, though
there
were plugboards that controlled the mechanical devices. I have known a
good
many people who made the transition from plugboards to programming
languages. (Some of whom survive to this very day, but not a high
percentage.)

I'm afraid 2205 was a misprint for 2025, I was being sarcastic which isn't
my metier

[com]

On Fri, 07 Apr 2006 07:08:52 GMT, "Larry Linson" <bo*****@localhost.not> wrote:

Ok, "if you program in 2022 and 2023, will you have to get a new resource to
program in 2025?". It depends -- if some person or company has released a
startling, new technology that they can sell to your management/clients as
being more cost effective, more productive, etc., probably yes. If you were
a COBOL programmer asking that question a few years back, in retrospect, the
answer should have been "No." Because, now, as a generation of COBOL
programmers is retiring, the demand for COBOL talent is so great, that
various organizations are having to give their employees "crash courses" in
COBOL.

Larry Linson
Microsoft Access MVP

OK,but this was comparing two versions of .NET.
I suppose I ws wondering if the constant change in developer tools was ultimately in the best
interest of clients, who would prefer the whole process to be de-skilled I'm sure, or of developers,
who don't.

[Deano]

Larry Linson wrote:

Ok, "if you program in 2022 and 2023, will you have to get a new
resource to program in 2025?". It depends -- if some person or
company has released a startling, new technology that they can sell
to your management/clients as being more cost effective, more
productive, etc., probably yes. If you were a COBOL programmer asking
that question a few years back, in retrospect, the answer should have
been "No." Because, now, as a generation of COBOL programmers is
retiring, the demand for COBOL talent is so great, that various
organizations are having to give their employees "crash courses" in
COBOL.

Wow, that's happening *again*? I did a COBOL course back in 1999 when I
joined the world of IT.

[Larry Linson]

"Deano" <de***@mailinator.com> wrote

Wow, that's happening *again*? I did a COBOL course
back in 1999 when I joined the world of IT.

I think the operative word may be "still" rather than "again." There was a
"long dry spell" when not many new COBOL programmers were being trained.
And, of course, Fujitsu had to come along and create a COBOL compiler for
the DotNet environment after many had "preached the funeral" of COBOL as a
viable development language.

Remember "the death of the mainframe era"? Ever since that phrase was
coined, there has been an increase in use of mainframes every single year.
<SIGH>

Larry Linson
Microsoft Access MVP

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:PuJZf.453$8g3.273@trnddc02:

Remember "the death of the mainframe era"? Ever since that phrase
was coined, there has been an increase in use of mainframes every
single year.

I don't really think there are that many mainframes operating out
there any longer, in the sense that the term was used in the past
(with dumb terminals or their equivalent running processes for
hundreds or thousands of simultaneous users on a single machine).
The last time I used a mainframe for work was in my Accounts Payable
days back in the 80s (ending in 1988 when I came to NYC), and for
other purposes was using NYU's online library catalog in the early
90s. I don't know what my former employer users now, but NYU long
ago migrated library catalog access to a brower-based client and all
the dumb terminals were replaced with PCs.

I think that's exactly what's happened with most "mainframes." The
single machine may still be doing the processing, but the client is
now running on a remote machine, rather than on the "mainframe."

The Client/Server paradigm replaced the "terminal/mainframe" long
ago, seems to me.

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

[Larry Linson]

Client-server usage increased _dramatically_, but industry stats show
increased mainframe use (albeit not in the same range as client-server)
every year -- impressions to the contrary notwithstanding.

Client-server suited (and suits) _me_ fine -- I was in a position to buy a
PC and have it to use as my development machine when I retired, but even
"small" mainframes were out of my league. Even so, there are compute
intensive environments where mainframes are useful.

Larry Linson
Microsoft Access MVP
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Larry Linson" <bo*****@localhost.not> wrote in
news:PuJZf.453$8g3.273@trnddc02:

Remember "the death of the mainframe era"? Ever since that phrase
was coined, there has been an increase in use of mainframes every
single year.

I don't really think there are that many mainframes operating out
there any longer, in the sense that the term was used in the past
(with dumb terminals or their equivalent running processes for
hundreds or thousands of simultaneous users on a single machine).
The last time I used a mainframe for work was in my Accounts Payable
days back in the 80s (ending in 1988 when I came to NYC), and for
other purposes was using NYU's online library catalog in the early
90s. I don't know what my former employer users now, but NYU long
ago migrated library catalog access to a brower-based client and all
the dumb terminals were replaced with PCs.

I think that's exactly what's happened with most "mainframes." The
single machine may still be doing the processing, but the client is
now running on a remote machine, rather than on the "mainframe."

The Client/Server paradigm replaced the "terminal/mainframe" long
ago, seems to me.

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