|
Home > Archive > MS Access database support > April 2006 > Access v dot net
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| 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 2006-04-03, 9:35 am |
| "Deano" <deano@mailinator.com> wrote in
news:443116ff$0$9237
$ed2619ec@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 2006-04-03, 11:32 am |
| Lyle Fairfield wrote:
> "Deano" <deano@mailinator.com> wrote in
> news:443116ff$0$9237
$ed2619ec@ptn-nntp-reader01.plus.net:
>
>
> 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 2006-04-03, 1:33 pm |
| 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@mailinator.com> wrote in message
news:443116ff$0$9237
$ed2619ec@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?
>
>
>
| |
|
| Jerry Boone wrote:[color=darkred
]
> 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@mailinator.com> wrote in message
> news:443116ff$0$9237
$ed2619ec@ptn-nntp-reader01.plus.net...
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 2006-04-03, 8:28 pm |
| 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
| |
|
| 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.
| |
|
| rkc wrote:
> Deano wrote:
>
> 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.
| |
|
| 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 2006-04-04, 8:30 pm |
| On Mon, 03 Apr 2006 13:49:50 GMT, Lyle Fairfield <lylefairfield@aim.com> wrote:
>"Deano" <deano@mailinator.com> wrote in
> news:443116ff$0$9237
$ed2619ec@ptn-nntp-reader01.plus.net:
>
>
>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 2006-04-06, 11:34 am |
| 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@mailinator.com> wrote in message
news:44319d28$0$9268
$ed2619ec@ptn-nntp-reader01.plus.net...
> Jerry Boone wrote:
>
> 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 2006-04-06, 1:34 pm |
| "Jerry Boone" <jerry@gomaps.com.nospam> wrote in
news:44353ffb$0$3694
$5426a0f7@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
| |
|
| On Thu, 6 Apr 2006 11:21:42 -0500, "Jerry Boone" <jerry@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 2006-04-06, 8:29 pm |
| "com" <com@com.com> wrote
>
> 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.)
| |
|
| On Thu, 06 Apr 2006 19:48:54 GMT, "Larry Linson" <bouncer@localhost.not> wrote:
>"com" <com@com.com> wrote
>
>
>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 2006-04-07, 3:44 am |
| 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" <com@com.com> wrote in message
news:snsa32tqj7g8iqi
haoj4fasikg89aibqqj@
4ax.com...
> On Thu, 06 Apr 2006 19:48:54 GMT, "Larry Linson" <bouncer@localhost.not>
> wrote:
>
> I'm afraid 2205 was a misprint for 2025, I was being sarcastic which isn't
> my metier
>
| |
|
| On Fri, 07 Apr 2006 07:08:52 GMT, "Larry Linson" <bouncer@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 2006-04-07, 11:32 am |
| 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 2006-04-08, 3:27 am |
| "Deano" <deano@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 2006-04-08, 9:27 am |
| "Larry Linson" <bouncer@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/
|
|
|
|
|