Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages of
dot.NET and upgrading to vb.NET seems like a good idea for the future. I'm
also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however I'm
not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do developers
make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the deployment
of apps and what you actually need to do. How good is dot.NET in this area?
I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right? Does
the mainform/subform concept exist in some way? I have important forms that
depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the data they
have created. Is this fairly straightforward process once I become familiar
with ado.NET?
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
regards
Martin
22  2188 
Hi Deano,
I think that there are not so much active Access developers in this
newsgroup with current Access experience.
This means that when you want answers comparing with Access in my opinion
you never get a complete answer. (Only from the ones who did make the step a
short time ago).
Access is a subset from the complete development area, this means that it is
in some parts very effective and it wills probably in those parts need more
work when you are using a real development language.
On the other hand can there with dotNet, many things be done which are
impossible with Access.
When you do not need those, yea that is your decision.
Just my thought,
Cor
Hi Deano,
I think that there are not so much active Access developers in this
newsgroup with current Access experience.
This means that when you want answers comparing with Access in my opinion
you never get a complete answer. (Only from the ones who did make the step a
short time ago).
Access is a subset from the complete development area, this means that it is
in some parts very effective and it wills probably in those parts need more
work when you are using a real development language.
On the other hand can there with dotNet, many things be done which are
impossible with Access.
When you do not need those, yea that is your decision.
Just my thought,
Cor
Hi Deano,
I'm already in the process of doing what you intend, so please understand
that my comments, whilst from an Access "expert", are from a dotnet newbie.
Any dotnet experts please help out if I get anything wrong! 1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
Crystal Reports, presumably, but I haven't got around to reports in my app
yet so I can't comment on CR as against Access reports.
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
Haven't deployed with dotnet yet, but I don't quite see how you expect to
update apps without sending SOMETHING out, whether by CD or via the web or
whatever? I've sometimes found deploying Access apps to be very
troublesome: dotnet surely cannot be worse!
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
Yep, no subforms. You need to be prepared to redesign your user interface
if you really want to do this. I believe there are ways to cobble together
some Access-like features in Windows Forms, but Access it ain't. I am using
data grids to display data where in Access I would use a continuous subform,
and am moving to a completely Wizard-based approach to editing/entering data
e.g. if user wants to create a new record, they click on the relevant
button, a series of forms guides them through the data entry, and the
resulting record then appears in the data grid. I see this as a positive
move: in my experience, entering data directly into complex Access forms
confuses the hell out of users. But, if you must have subforms and
continuous forms, stick with Access: those are it's greatest strengths, and
there is nothing else like it, AFAIK.
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
What database engine? SQL Server? When I have done Access apps with linked
SQL Server tables, I have created menu options that allow the user to backup
the database to a disk file, and also to create a schedule to do this
automatically every day (using SQL Server Agent). This is quite
straightforward, and is more a SQL Server issue than a client technology
issue. I expect to implement the same approach using dotnet.
HTH
Baz
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
regards
Martin
Hi Deano,
I'm already in the process of doing what you intend, so please understand
that my comments, whilst from an Access "expert", are from a dotnet newbie.
Any dotnet experts please help out if I get anything wrong! 1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
Crystal Reports, presumably, but I haven't got around to reports in my app
yet so I can't comment on CR as against Access reports.
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
Haven't deployed with dotnet yet, but I don't quite see how you expect to
update apps without sending SOMETHING out, whether by CD or via the web or
whatever? I've sometimes found deploying Access apps to be very
troublesome: dotnet surely cannot be worse!
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
Yep, no subforms. You need to be prepared to redesign your user interface
if you really want to do this. I believe there are ways to cobble together
some Access-like features in Windows Forms, but Access it ain't. I am using
data grids to display data where in Access I would use a continuous subform,
and am moving to a completely Wizard-based approach to editing/entering data
e.g. if user wants to create a new record, they click on the relevant
button, a series of forms guides them through the data entry, and the
resulting record then appears in the data grid. I see this as a positive
move: in my experience, entering data directly into complex Access forms
confuses the hell out of users. But, if you must have subforms and
continuous forms, stick with Access: those are it's greatest strengths, and
there is nothing else like it, AFAIK.
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
What database engine? SQL Server? When I have done Access apps with linked
SQL Server tables, I have created menu options that allow the user to backup
the database to a disk file, and also to create a schedule to do this
automatically every day (using SQL Server Agent). This is quite
straightforward, and is more a SQL Server issue than a client technology
issue. I expect to implement the same approach using dotnet.
HTH
Baz
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
regards
Martin
Hi Martin
I would get a clean piece of paper of paper, and start again.
My personal feeling is that things should do what they do best. For Access,
that is database management, and not user interfaces, so I applaud your
decision to move to a language such as VB.NET. Apart from anything else, you
will find a later move to a different database (should you choose) a breeze.
Access and VB.NET are sufficiently different that apart from the odd clever
algorithm that can be cut and pasted, I would not think in terms of porting
code, but redesign and recode. Having been persuaded in the past to port
from Access to classic VB (against my better judgement), I'm firmly of the
opinion that you will reap the benefits quite soon.
With regard to reporting, a good starting point is Crystal Reports. Some
people love it, and others hate it, but it is as good as most other tools,
and they all have their vagaries.
HTH
Charles
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
regards
Martin
Hi Martin
I would get a clean piece of paper of paper, and start again.
My personal feeling is that things should do what they do best. For Access,
that is database management, and not user interfaces, so I applaud your
decision to move to a language such as VB.NET. Apart from anything else, you
will find a later move to a different database (should you choose) a breeze.
Access and VB.NET are sufficiently different that apart from the odd clever
algorithm that can be cut and pasted, I would not think in terms of porting
code, but redesign and recode. Having been persuaded in the past to port
from Access to classic VB (against my better judgement), I'm firmly of the
opinion that you will reap the benefits quite soon.
With regard to reporting, a good starting point is Crystal Reports. Some
people love it, and others hate it, but it is as good as most other tools,
and they all have their vagaries.
HTH
Charles
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
regards
Martin
(Aside to Cor)... I'm still semi-active, mostly for those apps that I wrote
before starting to use .Net. So I'll give this one a go...
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
Visual Studio comes with Crystal Reports built in. So I'd guess that that
counts as the 'recommended' tool. Speaking for myself, I absolutely detest
Crystal. It may be that I was missing something, but (for example) when I
updated the data source I occasionally needed to rewrite entire reports.
I've actually moved to using Excel for reporting (...create a new workbook
and push the data at it...). That obviously only really works for
non-relational data, but so far I'm getting away with it.
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
I don't think you're going to avoid sending out the CD. The standard (and
very straightforward) installation method is to create an msi installer.
When I'm updating at the moment I'm doing it over a LAN, so I can just
create a new msi and overwrite.
I'm sure you could set up your original app with one msi to install the
data, and another to install the GUI, and then just update the GUI, but I
don't think there's a way of getting VS.Net to create msp files to just
patch existing installations. There may be a tool to do this somewhere
though.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
Lots of recoding/relearning I'm afraid. Subforms (as such) don't exist but
the functionality exists in creating disconnected recordsets containing
relationships. Your best bet would be to go through some of the
walkthroughs _before_ doing any live coding.
Other big differences are that: (as far as I've seen) .Net works far more on
the 'loop through a recordset' methodology; far more coding required (e.g.
if you want a check box to behave sensibly in a continuous form style then
you have about 4 subroutines set up for different events... MouseUp,
MouseDown etc). There's quite a lot of stuff that is inherently dealt with
by Access that you have to code explicitly for in .Net (e.g. data
concurrency in multi-user situations)
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
I haven't tried that one, but it should be very straightforward. If, for
example, you're putting the data into mdbs then it should just be a case of
copying different file versions backwards and forwards.
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
One last point. The help files in Visual Studio are woeful (at least until
you get used to how they work, at which point they move to just 'not very
good'). And given that .Net is a newer technology there is far less help
available over the net. So you'll be doing a great deal more banging your
head on the desk. Might be worth getting some kind of support contract from
MS before starting work for real.
regards
Martin
Good luck.
(Aside to Cor)... I'm still semi-active, mostly for those apps that I wrote
before starting to use .Net. So I'll give this one a go...
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing using an
Access runtime. This works fine (mostly) but I'm sold on the advantages
of dot.NET and upgrading to vb.NET seems like a good idea for the future.
I'm also keen to develop new software in vb.NET as soon as possible.
I will work out how to port the app and how to use ado.NET etc, however
I'm not certain about all the things I need to consider hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
Visual Studio comes with Crystal Reports built in. So I'd guess that that
counts as the 'recommended' tool. Speaking for myself, I absolutely detest
Crystal. It may be that I was missing something, but (for example) when I
updated the data source I occasionally needed to rewrite entire reports.
I've actually moved to using Excel for reporting (...create a new workbook
and push the data at it...). That obviously only really works for
non-relational data, but so far I'm getting away with it.
2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment of apps and what you actually need to do. How good is dot.NET in this
area? I'd love to develop a windows forms app that could be updated without
sending out a CD etc.
I don't think you're going to avoid sending out the CD. The standard (and
very straightforward) installation method is to create an msi installer.
When I'm updating at the moment I'm doing it over a LAN, so I can just
create a new msi and overwrite.
I'm sure you could set up your original app with one msi to install the
data, and another to install the GUI, and then just update the GUI, but I
don't think there's a way of getting VS.Net to create msp files to just
patch existing installations. There may be a tool to do this somewhere
though.
3. Possibly critical differences when moving from Access. I read that
there aren't any subforms in dot.NET or windows forms. Is this right?
Does the mainform/subform concept exist in some way? I have important forms
that depend on this and I can't see a way around this. Does anyone know of any
other issues when moving from Access to dot.NET apart from recoding etc?
Lots of recoding/relearning I'm afraid. Subforms (as such) don't exist but
the functionality exists in creating disconnected recordsets containing
relationships. Your best bet would be to go through some of the
walkthroughs _before_ doing any live coding.
Other big differences are that: (as far as I've seen) .Net works far more on
the 'loop through a recordset' methodology; far more coding required (e.g.
if you want a check box to behave sensibly in a continuous form style then
you have about 4 subroutines set up for different events... MouseUp,
MouseDown etc). There's quite a lot of stuff that is inherently dealt with
by Access that you have to code explicitly for in .Net (e.g. data
concurrency in multi-user situations)
4. User data. My app allows the user to back up and restore the data
they have created. Is this fairly straightforward process once I become
familiar with ado.NET?
I haven't tried that one, but it should be very straightforward. If, for
example, you're putting the data into mdbs then it should just be a case of
copying different file versions backwards and forwards.
The app is confined to working on the user's pc and no server elements are
involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum or ask
for something that converts code to dot.NET).
One last point. The help files in Visual Studio are woeful (at least until
you get used to how they work, at which point they move to just 'not very
good'). And given that .Net is a newer technology there is far less help
available over the net. So you'll be doing a great deal more banging your
head on the desk. Might be worth getting some kind of support contract from
MS before starting work for real.
regards
Martin
Good luck.
Hi Baz, 2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment
The integrated deployment in dotNet is very good (deployment projects).
However, it is not a one touch deployment or update. (One of the major
points from the next version is that the deployment will be much better, and
when that is told that means from the current, you understand it I suppose)
A fine thing from dotNet is that when the user has the right dotNet
framework on his computer you only have to deploy the program files. (The
MSI as Rob stated.)
Not any more run timers as by instance in VB6 or other things that has to be
deployed extra.
Therefore, it is in my opinion better to use as less as possible so-called
COM elements to your VBnet programs. Examples do not use Recordsets (you
need to add Ado dll's).
However, that is not always possible, when there is no replacement, than you
have to
This is just trying to make your message more complete on a point where I
thought you where asked for that.
Cor
Hi Baz, 2. Deployment/Remote updating of the app. I know from experience that
there is a world of difference between the theory concerting the
deployment
The integrated deployment in dotNet is very good (deployment projects).
However, it is not a one touch deployment or update. (One of the major
points from the next version is that the deployment will be much better, and
when that is told that means from the current, you understand it I suppose)
A fine thing from dotNet is that when the user has the right dotNet
framework on his computer you only have to deploy the program files. (The
MSI as Rob stated.)
Not any more run timers as by instance in VB6 or other things that has to be
deployed extra.
Therefore, it is in my opinion better to use as less as possible so-called
COM elements to your VBnet programs. Examples do not use Recordsets (you
need to add Ado dll's).
However, that is not always possible, when there is no replacement, than you
have to
This is just trying to make your message more complete on a point where I
thought you where asked for that.
Cor
Thanks Cor, that's useful information.
Baz
"Cor" <no*@non.com> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl... Hi Baz,
2. Deployment/Remote updating of the app. I know from experience
that there is a world of difference between the theory concerting the deployment
The integrated deployment in dotNet is very good (deployment projects).
However, it is not a one touch deployment or update. (One of the major
points from the next version is that the deployment will be much better,
and when that is told that means from the current, you understand it I
suppose)
A fine thing from dotNet is that when the user has the right dotNet
framework on his computer you only have to deploy the program files. (The
MSI as Rob stated.)
Not any more run timers as by instance in VB6 or other things that has to
be deployed extra.
Therefore, it is in my opinion better to use as less as possible so-called
COM elements to your VBnet programs. Examples do not use Recordsets (you
need to add Ado dll's).
However, that is not always possible, when there is no replacement, than
you have to
This is just trying to make your message more complete on a point where I
thought you where asked for that.
Cor
Thanks Cor, that's useful information.
Baz
"Cor" <no*@non.com> wrote in message
news:eB**************@TK2MSFTNGP11.phx.gbl... Hi Baz,
2. Deployment/Remote updating of the app. I know from experience
that there is a world of difference between the theory concerting the deployment
The integrated deployment in dotNet is very good (deployment projects).
However, it is not a one touch deployment or update. (One of the major
points from the next version is that the deployment will be much better,
and when that is told that means from the current, you understand it I
suppose)
A fine thing from dotNet is that when the user has the right dotNet
framework on his computer you only have to deploy the program files. (The
MSI as Rob stated.)
Not any more run timers as by instance in VB6 or other things that has to
be deployed extra.
Therefore, it is in my opinion better to use as less as possible so-called
COM elements to your VBnet programs. Examples do not use Recordsets (you
need to add Ado dll's).
However, that is not always possible, when there is no replacement, than
you have to
This is just trying to make your message more complete on a point where I
thought you where asked for that.
Cor
Baz wrote: Hi Deano,
I'm already in the process of doing what you intend, so please
understand that my comments, whilst from an Access "expert", are from
a dotnet newbie. Any dotnet experts please help out if I get anything
wrong!
It's good to know someone else is in the same boat as me :)
3. Possibly critical differences when moving from Access. I read
that there aren't any subforms in dot.NET or windows forms. Is this
right? Does the mainform/subform concept exist in some way? I have
important forms that depend on this and I can't see a way around
this. Does anyone know of any other issues when moving from Access
to dot.NET apart from recoding etc?
Yep, no subforms. You need to be prepared to redesign your user
interface if you really want to do this. I believe there are ways to
cobble together some Access-like features in Windows Forms, but
Access it ain't. I am using data grids to display data where in
Access I would use a continuous subform, and am moving to a
completely Wizard-based approach to editing/entering data e.g. if
user wants to create a new record, they click on the relevant button,
a series of forms guides them through the data entry, and the
resulting record then appears in the data grid. I see this as a
positive move: in my experience, entering data directly into complex
Access forms confuses the hell out of users. But, if you must have
subforms and continuous forms, stick with Access: those are it's
greatest strengths, and there is nothing else like it, AFAIK.
I did see a Master/details set up in Professional vb.net in the bookstore
today, so maybe something approaching what i have is possible. Certainly a
big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough and I've
already had irritating deployment issues that I want to avoid in the future.
4. User data. My app allows the user to back up and restore the
data they have created. Is this fairly straightforward process once
I become familiar with ado.NET?
What database engine? SQL Server? When I have done Access apps with
linked SQL Server tables, I have created menu options that allow the
user to backup the database to a disk file, and also to create a
schedule to do this automatically every day (using SQL Server Agent).
This is quite straightforward, and is more a SQL Server issue than a
client technology issue. I expect to implement the same approach
using dotnet.
I don't know really - in Access I just create an mdb that the user can
backup somewhere. I expect to be able to do something similar using vb.NET
and once I decide how to store the data.
Would I be able to ship something like MSDE with the app and connect to that
locally using ado.NET?
HTH
Baz
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing
using an Access runtime. This works fine (mostly) but I'm sold on
the advantages of dot.NET and upgrading to vb.NET seems like a good
idea for the future. I'm also keen to develop new software in vb.NET
as soon as possible.
I will work out how to port the app and how to use ado.NET etc,
however I'm not certain about all the things I need to consider
hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience
that there is a world of difference between the theory concerting
the deployment of apps and what you actually need to do. How good
is dot.NET in this area? I'd love to develop a windows forms app
that could be updated without sending out a CD etc.
3. Possibly critical differences when moving from Access. I read
that there aren't any subforms in dot.NET or windows forms. Is this
right? Does the mainform/subform concept exist in some way? I have
important forms that depend on this and I can't see a way around
this. Does anyone know of any other issues when moving from Access
to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the
data they have created. Is this fairly straightforward process once
I become familiar with ado.NET?
The app is confined to working on the user's pc and no server
elements are involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum
or ask for something that converts code to dot.NET).
regards
Martin
Baz wrote: Hi Deano,
I'm already in the process of doing what you intend, so please
understand that my comments, whilst from an Access "expert", are from
a dotnet newbie. Any dotnet experts please help out if I get anything
wrong!
It's good to know someone else is in the same boat as me :)
3. Possibly critical differences when moving from Access. I read
that there aren't any subforms in dot.NET or windows forms. Is this
right? Does the mainform/subform concept exist in some way? I have
important forms that depend on this and I can't see a way around
this. Does anyone know of any other issues when moving from Access
to dot.NET apart from recoding etc?
Yep, no subforms. You need to be prepared to redesign your user
interface if you really want to do this. I believe there are ways to
cobble together some Access-like features in Windows Forms, but
Access it ain't. I am using data grids to display data where in
Access I would use a continuous subform, and am moving to a
completely Wizard-based approach to editing/entering data e.g. if
user wants to create a new record, they click on the relevant button,
a series of forms guides them through the data entry, and the
resulting record then appears in the data grid. I see this as a
positive move: in my experience, entering data directly into complex
Access forms confuses the hell out of users. But, if you must have
subforms and continuous forms, stick with Access: those are it's
greatest strengths, and there is nothing else like it, AFAIK.
I did see a Master/details set up in Professional vb.net in the bookstore
today, so maybe something approaching what i have is possible. Certainly a
big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough and I've
already had irritating deployment issues that I want to avoid in the future.
4. User data. My app allows the user to back up and restore the
data they have created. Is this fairly straightforward process once
I become familiar with ado.NET?
What database engine? SQL Server? When I have done Access apps with
linked SQL Server tables, I have created menu options that allow the
user to backup the database to a disk file, and also to create a
schedule to do this automatically every day (using SQL Server Agent).
This is quite straightforward, and is more a SQL Server issue than a
client technology issue. I expect to implement the same approach
using dotnet.
I don't know really - in Access I just create an mdb that the user can
backup somewhere. I expect to be able to do something similar using vb.NET
and once I decide how to store the data.
Would I be able to ship something like MSDE with the app and connect to that
locally using ado.NET?
HTH
Baz
"Deano" <de*********@hotmail.com> wrote in message
news:Ux*********************@wards.force9.net... Hi,
I have a finished Microsoft Access app that we are distributing
using an Access runtime. This works fine (mostly) but I'm sold on
the advantages of dot.NET and upgrading to vb.NET seems like a good
idea for the future. I'm also keen to develop new software in vb.NET
as soon as possible.
I will work out how to port the app and how to use ado.NET etc,
however I'm not certain about all the things I need to consider
hence the questions;
1. Reporting. I will miss Access' report generator. Is there a
recommended third-party app for this? What other arrangements do
developers make when using vb.NET?
2. Deployment/Remote updating of the app. I know from experience
that there is a world of difference between the theory concerting
the deployment of apps and what you actually need to do. How good
is dot.NET in this area? I'd love to develop a windows forms app
that could be updated without sending out a CD etc.
3. Possibly critical differences when moving from Access. I read
that there aren't any subforms in dot.NET or windows forms. Is this
right? Does the mainform/subform concept exist in some way? I have
important forms that depend on this and I can't see a way around
this. Does anyone know of any other issues when moving from Access
to dot.NET apart from recoding etc?
4. User data. My app allows the user to back up and restore the
data they have created. Is this fairly straightforward process once
I become familiar with ado.NET?
The app is confined to working on the user's pc and no server
elements are involved.
Many thanks for any comments, links etc (I have done a fair amount of
research on Google Groups but Access-related posts are at a minimum
or ask for something that converts code to dot.NET).
regards
Martin
Rob Oldfield wrote:
<big snip>
Thanks for all the replies. I have a simpler app in mind that will be a
good first use of vb.NET and I think thereafter I will try to port our
existing app - though hopefully it the money is pouring in I'll be hiring a
developer to do all the hard work :)
Rob Oldfield wrote:
<big snip>
Thanks for all the replies. I have a simpler app in mind that will be a
good first use of vb.NET and I think thereafter I will try to port our
existing app - though hopefully it the money is pouring in I'll be hiring a
developer to do all the hard work :)
Sounds like a damn cunning plan. As far as I can see it's one of those that
can only be upset by reality.
"Deano" <de*********@hotmail.com> wrote in message
news:4f*********************@wards.force9.net... Rob Oldfield wrote:
<big snip>
Thanks for all the replies. I have a simpler app in mind that will be a
good first use of vb.NET and I think thereafter I will try to port our
existing app - though hopefully it the money is pouring in I'll be hiring
a developer to do all the hard work :)
Sounds like a damn cunning plan. As far as I can see it's one of those that
can only be upset by reality.
"Deano" <de*********@hotmail.com> wrote in message
news:4f*********************@wards.force9.net... Rob Oldfield wrote:
<big snip>
Thanks for all the replies. I have a simpler app in mind that will be a
good first use of vb.NET and I think thereafter I will try to port our
existing app - though hopefully it the money is pouring in I'll be hiring
a developer to do all the hard work :)
Hi again Martin.
I did see a Master/details set up in Professional vb.net in the bookstore
today, so maybe something approaching what i have is possible. Certainly
a big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough and
I've already had irritating deployment issues that I want to avoid in the
future.
Yes, that's the sort of thing I have seen. However, it will never have the
power and sophistication of Access subforms/continuous forms, so rather than
trying to make Windows Forms into something they don't really want to be,
I've decided to "go with the flow", and start from scratch with the user
interface.
I agree about Access/DAO: that's why I decided to switch. I want my app to
be able to be reliably shipped, installed and used without any IT support
being needed.
I don't know really - in Access I just create an mdb that the user can
backup somewhere. I expect to be able to do something similar using
vb.NET and once I decide how to store the data.
Obviously with an mdb a backup simply means copying a file! I'm not sure
what specific backup features you would expect to offer.
Would I be able to ship something like MSDE with the app and connect to
that locally using ado.NET?
Absolutely. It's what I'm doing. I used also to do it with Access apps
with linked SQL Server tables. VB.Net has better integration with SQL
Server than with any other database engine, and you can do stuff like
drag-and-drop database objects (tables, views, stored procedures) in order
to create dataset objects without even writing any code. It's neat, once
you get the hang of it.
Frankly, if you want to go dotnet, then SQL Server (MSDE) is the smart way
to go: if you wanted to stick with mdb, I would recommend sticking with
Access.
Do not, however, get the idea that I am wholeheartedly endorsing dotnet!
It's a breathtakingly ambitious undertaking by Microsoft, and the inevitable
result is that, from the developer's perspective, it is buggy and quirky.
That's fine for experts who've taken all the pratfalls and know how to avoid
them, but for newbies like us it can be very frustrating at times!
HTH
Baz
Hi again Martin.
I did see a Master/details set up in Professional vb.net in the bookstore
today, so maybe something approaching what i have is possible. Certainly
a big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough and
I've already had irritating deployment issues that I want to avoid in the
future.
Yes, that's the sort of thing I have seen. However, it will never have the
power and sophistication of Access subforms/continuous forms, so rather than
trying to make Windows Forms into something they don't really want to be,
I've decided to "go with the flow", and start from scratch with the user
interface.
I agree about Access/DAO: that's why I decided to switch. I want my app to
be able to be reliably shipped, installed and used without any IT support
being needed.
I don't know really - in Access I just create an mdb that the user can
backup somewhere. I expect to be able to do something similar using
vb.NET and once I decide how to store the data.
Obviously with an mdb a backup simply means copying a file! I'm not sure
what specific backup features you would expect to offer.
Would I be able to ship something like MSDE with the app and connect to
that locally using ado.NET?
Absolutely. It's what I'm doing. I used also to do it with Access apps
with linked SQL Server tables. VB.Net has better integration with SQL
Server than with any other database engine, and you can do stuff like
drag-and-drop database objects (tables, views, stored procedures) in order
to create dataset objects without even writing any code. It's neat, once
you get the hang of it.
Frankly, if you want to go dotnet, then SQL Server (MSDE) is the smart way
to go: if you wanted to stick with mdb, I would recommend sticking with
Access.
Do not, however, get the idea that I am wholeheartedly endorsing dotnet!
It's a breathtakingly ambitious undertaking by Microsoft, and the inevitable
result is that, from the developer's perspective, it is buggy and quirky.
That's fine for experts who've taken all the pratfalls and know how to avoid
them, but for newbies like us it can be very frustrating at times!
HTH
Baz
Baz wrote: Hi again Martin.
I did see a Master/details set up in Professional vb.net in the
bookstore today, so maybe something approaching what i have is
possible. Certainly a big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough
and I've already had irritating deployment issues that I want to
avoid in the future.
Yes, that's the sort of thing I have seen. However, it will never
have the power and sophistication of Access subforms/continuous
forms, so rather than trying to make Windows Forms into something
they don't really want to be, I've decided to "go with the flow", and
start from scratch with the user interface.
This makes me wonder how professional developers decide to create their
interfaces. You see some very specific looking stuff that must be coded in
C/C++ and they must build custom components to achieve certain things. I
doubt if I will ever get to that level so I will have to adjust the
application design to fit what is available, or "go with the flow" as you
say.
I don't know really - in Access I just create an mdb that the user
can backup somewhere. I expect to be able to do something similar
using vb.NET and once I decide how to store the data.
Obviously with an mdb a backup simply means copying a file! I'm not
sure what specific backup features you would expect to offer.
I actually create a new mdb when the user backups which contains specific
data that they have created. This file can be restored later so they can
have multiple data scenarios to play with and I can restore it to my master
version for support purposes.
<snipped>
Do not, however, get the idea that I am wholeheartedly endorsing
dotnet! It's a breathtakingly ambitious undertaking by Microsoft, and
the inevitable result is that, from the developer's perspective, it
is buggy and quirky. That's fine for experts who've taken all the
pratfalls and know how to avoid them, but for newbies like us it can
be very frustrating at times!
HTH
Baz
Thanks for your thoughts Baz, it's been very useful.
Baz wrote: Hi again Martin.
I did see a Master/details set up in Professional vb.net in the
bookstore today, so maybe something approaching what i have is
possible. Certainly a big rethink is on the cards.
I just think using Access and DAO is not going to be robust enough
and I've already had irritating deployment issues that I want to
avoid in the future.
Yes, that's the sort of thing I have seen. However, it will never
have the power and sophistication of Access subforms/continuous
forms, so rather than trying to make Windows Forms into something
they don't really want to be, I've decided to "go with the flow", and
start from scratch with the user interface.
This makes me wonder how professional developers decide to create their
interfaces. You see some very specific looking stuff that must be coded in
C/C++ and they must build custom components to achieve certain things. I
doubt if I will ever get to that level so I will have to adjust the
application design to fit what is available, or "go with the flow" as you
say.
I don't know really - in Access I just create an mdb that the user
can backup somewhere. I expect to be able to do something similar
using vb.NET and once I decide how to store the data.
Obviously with an mdb a backup simply means copying a file! I'm not
sure what specific backup features you would expect to offer.
I actually create a new mdb when the user backups which contains specific
data that they have created. This file can be restored later so they can
have multiple data scenarios to play with and I can restore it to my master
version for support purposes.
<snipped>
Do not, however, get the idea that I am wholeheartedly endorsing
dotnet! It's a breathtakingly ambitious undertaking by Microsoft, and
the inevitable result is that, from the developer's perspective, it
is buggy and quirky. That's fine for experts who've taken all the
pratfalls and know how to avoid them, but for newbies like us it can
be very frustrating at times!
HTH
Baz
Thanks for your thoughts Baz, it's been very useful. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jerome |
last post by:
Hi, I'm a bit confused ... when would I rather write an database
application using MS Access and Visual Basic and when (and why) would I
rather write it using Visual Studio .Net?
Is it as easy...
|
by: bill |
last post by:
I am trying to convince a client that dotNet is preferable to an Access
project (ADP/ADE).
This client currently has a large, pure Access MDB solution with 30+ users,
which needs to be upgraded....
|
by: Dave |
last post by:
Hello NG,
Regarding access-declarations and member using-declarations as used to
change the access level of an inherited base member...
Two things need to be considered when determining an...
|
by: Simon Bailey |
last post by:
I am a newcomer to databases and am not sure which DBMS to use. I have
a very simplified knowledge of databases overall. I would very much
appreciate a (simplifed) message explaining the advantages...
|
by: Frederick Noronha \(FN\) |
last post by:
---------- Forwarded message ----------
Solutions to Everyday User Interface and Programming Problems
O'Reilly Releases "Access Cookbook, Second Edition"
Sebastopol, CA--Neither reference book...
|
by: Olav.NET |
last post by:
I am a .NET/C++ developer who is supposed to do some work with Access.
I do not know much about it except for the DB part.
Questions:
*1*
I am looking for INTENSIVE books to get quickly up to...
|
by: John |
last post by:
Hi
What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.
...
|
by: com |
last post by:
Extreme Web Reports 2005 - Soft30.com
The wizard scans the specified MS Access database and records
information such
as report names, parameters and subqueries. ......
|
by: Mell via AccessMonster.com |
last post by:
Is there a way to find out where an application was created from?
i.e. - work or home
i.e. - if application sits on a (work) server/network, the IT people know the
application is sitting...
|
by: jasmith |
last post by:
How will Access fair in a year? Two years? .... The new version of
Access seems to service non programmers as a wizard interface to
quickly create databases via a fancy wizard. Furthermore, why...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
