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]

Re: Access v dot net

"Deano" <deano@mailinat or.com> wrote in
news:443116ff$0 $9237$ed2619ec@ ptn-nntp-reader01.plus.n et:
[color=blue]
> 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?[/color]

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]

Re: Access v dot net

Lyle Fairfield wrote:[color=blue]
> "Deano" <deano@mailinat or.com> wrote in
> news:443116ff$0 $9237$ed2619ec@ ptn-nntp-reader01.plus.n et:
>[color=green]
>> 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?[/color]
>
> 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.[/color]

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

[Jerry Boone]

Re: Access v dot net

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" <deano@mailinat or.com> wrote in message
news:443116ff$0 $9237$ed2619ec@ ptn-nntp-reader01.plus.n et...[color=blue]
> 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[/color]
replicate[color=blue]
> 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?
>
>
>[/color]

[Deano]

Re: Access v dot net

Jerry Boone wrote:[color=blue]
> 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" <deano@mailinat or.com> wrote in message
> news:443116ff$0 $9237$ed2619ec@ ptn-nntp-reader01.plus.n et...[color=green]
>> 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?[/color][/color]

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]

Re: Access v dot net

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]

Re: Access v dot net

Deano wrote:[color=blue]
>
> 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.[/color]

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]

Re: Access v dot net

rkc wrote:[color=blue]
> Deano wrote:[color=green]
>>
>> 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.[/color]
>
> 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.[/color]

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]

Re: Access v dot net

Jerry Boone wrote:[color=blue]
> 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.[/color]

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]

Re: Access v dot net

On Mon, 03 Apr 2006 13:49:50 GMT, Lyle Fairfield <lylefairfield@ aim.com> wrote:
[color=blue]
>"Deano" <deano@mailinat or.com> wrote in
>news:443116ff$ 0$9237$ed2619ec @ptn-nntp-reader01.plus.n et:
>[color=green]
>> 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?[/color]
>
>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.[/color]

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]

Re: Access v dot 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.
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" <deano@mailinat or.com> wrote in message
news:44319d28$0 $9268$ed2619ec@ ptn-nntp-reader01.plus.n et...[color=blue]
> Jerry Boone wrote:[color=green]
> > 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.[/color]
>
> 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[/color]
on[color=blue]
> 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[/color]
setup[color=blue]
> in .NET but I like the way that Access presents this info, i.e being able[/color]
to[color=blue]
> 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,[/color]
things[color=blue]
> 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[/color]
to[color=blue]
> 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[/color]
to[color=blue]
> test out .NET.
>
>[/color]

[Lyle Fairfield]

Re: Access v dot net

"Jerry Boone" <jerry@gomaps.c om.nospam> wrote in
news:44353ffb$0 $3694$5426a0f7@ news.hubris.net :
[color=blue]
> 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.[/color]

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]

Re: Access v dot net

On Thu, 6 Apr 2006 11:21:42 -0500, "Jerry Boone" <jerry@gomaps.c om.nospam> wrote (in part):
[color=blue]
>This book mainly applies to 2002/2003 .NET so if you are going to use .NET
>2005 you may want a different resource.[/color]

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]

Re: Access v dot net

"com" <com@com.com> wrote
[color=blue][color=green]
>> This book mainly applies to 2002/2003 .NET so
>> if you are going to use .NET 2005 you may want
>> a different resource.[/color]
>
> 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![/color]

If there is "programmin g" 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 "programmin g 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]

Re: Access v dot net

On Thu, 06 Apr 2006 19:48:54 GMT, "Larry Linson" <bouncer@localh ost.not> wrote:
[color=blue]
>"com" <com@com.com> wrote
>[color=green][color=darkred]
> >> This book mainly applies to 2002/2003 .NET so
> >> if you are going to use .NET 2005 you may want
> >> a different resource.[/color]
> >
> > 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![/color]
>
>If there is "programmin g" 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 "programmin g 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.)
>
>[/color]
I'm afraid 2205 was a misprint for 2025, I was being sarcastic which isn't my metier