Are there rules/policy for creating a new ADO VS project to a solution? When
should I create a new ADO project for a VS solution? Is there anything like
a limit to the number of object files you can have to a VS project?

Background:
I have a top level local business getter application/project (lets call it
ProjectA). One of the things this project links to/gets is an Access ADO
application (DataSet, etc) for one particular database. The ADO files are
physically located in ProjectA and, use an Interface file I wrote.

Now, I need to use this same Interface file/template and write additional
ADO type applications for other/different databases which need to be
accessible from ProjectA.

Should I:
- Copy and save the existing solution ADO application files into a ProjectB
so I now have a VS ProjectA and an ProjectB (other ADO applications will be
placed into a ProjectC, ProjectD, etc)
- Keep everything in ProjectA? (very messy)
- Start all new ADO applications from this point forward into separate
projects?

AND (most important) where should I place that ADO Interface file so I can
get at it? How do I get at it?

I hope I haven’t lost you. Please/requestyou take the time to respond or
point me in a direction.

Steve

Steve,

I think that you make it yourself difficult to get an answer, when you ask
a question you should at least use the elementary names as used in the
language.

ADO is as well called ADODB which uses Recordsets
ADONET uses Datasets.

Starting reading your text, gave me the idea you where using ADO while going
on it became ADONET.

Than I thought he wants to create an interface using his ADO code with
ADONet. However than it did not sound reasonable as well reading the text.

Getting a solution means first writting the problem down right, that is
elementary with development in my opinion.

You can use both in VS Net by the way, although ADONET is much prefered.

I hope this helps something?

Cor

Cor

Thanks for responding and the info

In using ADONet. and connecting to the database using MS.Jet.OLEDB
connection. The Interface file contains common ADONet type set/get methods
common to ADONet applications (DataSet, DataTable, DataGrid, ErrorProvider,
seaching, etc). The following are few stubs from the interface

//General data
DataGrid setGridCaption(..);
DataGrid SetCellWithFocus(...);
DataGrid setGridNamesAndWidth(...);
DataGrid moveDataGridIndex(...);

Steve
"Cor Ligthert" wrote:

> Steve,
>
> I think that you make it yourself difficult to get an answer, when you ask
> a question you should at least use the elementary names as used in the
> language.
>
> ADO is as well called ADODB which uses Recordsets
> ADONET uses Datasets.
>
> Starting reading your text, gave me the idea you where using ADO while going
> on it became ADONET.
>
> Than I thought he wants to create an interface using his ADO code with
> ADONet. However than it did not sound reasonable as well reading the text.
>
> Getting a solution means first writting the problem down right, that is
> elementary with development in my opinion.
>
> You can use both in VS Net by the way, although ADONET is much prefered.
>
> I hope this helps something?
>
> Cor
>
>
>

Steve,

This is easy to answer, one of the reasons for OOP is reusability. That
would be not much when you copied it in your project or was using it from
another project. In my opinion when you would use it in more projects you
should at least seperate it in one seperated namespace and DLL.

(An approach, create a Dynamic Link Library copy your old project in it, and
start with that to remove everything not direct for data, use that for
project B, and maintenance as soon as possible after that Project A. Watch
that you do not change major things that can bring you in problem for the
last)

Just my thought,

Cor

Thank You

I understand OOP/OOD but my problem is I don't really understand
development/OS environments I can program almost anything but that doesn't
help me if I don't know if I'm writing ADO or ADONet. For example, I know
what a development library is but I don't really know what a DLL is even
though my application is full them and I use Interop DLL's as references to
ProjectA

I guess what your saying is the Interface should become a DLL for other
namespaces to access - I agree. Right now the top level files and the ADONet
files are all mixed up together and I know that's wrong. I'll have to do
some research. Note: When I started this task I said to myself "I'll deal
with it later" - now is later.

Thanks
Steve

"Cor Ligthert" wrote:

> Steve,
>
> This is easy to answer, one of the reasons for OOP is reusability. That
> would be not much when you copied it in your project or was using it from
> another project. In my opinion when you would use it in more projects you
> should at least seperate it in one seperated namespace and DLL.
>
> (An approach, create a Dynamic Link Library copy your old project in it, and
> start with that to remove everything not direct for data, use that for
> project B, and maintenance as soon as possible after that Project A. Watch
> that you do not change major things that can bring you in problem for the
> last)
>
> Just my thought,
>
> Cor
>
>
>