snapdal-devel Mailing List for SnapDAL for .Net

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

hi snapdal

http://nortonenergydrillingllc.com/tone.php?cross=c1u44zpdv8f1wz

Philip Nelson

Vaporware no more. I suppose calling this a beta is awfully conservative, but
I'm hoping that once 1.0 hits, I won't have many nagging things on my wish
list. This is getting close now. At the same time, more users are using SnapDAL
so perhaps user driven requests will change it's shape some. That would be a
very good thing of course, so make your comments, send tests of broken code,
ask for clarification, suggest documentation that woulld have shortened you
learning curve.

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Sounds good! 

-----Original Message-----
From: sna...@li...
[mailto:sna...@li...] On Behalf Of Philip
Nelson
Sent: Wednesday, June 01, 2005 5:24 PM
To: sna...@li...
Subject: Re: [snapdal-devel] Stored Statement names

Look for a file called Statements.xml as an example. This allows all the
statments to be in a single file. In addition, you can use include
statements in Statements.xml if you want to separate them out by certain
functions.

In the version I will release "real soon now" you can also specify a class
that has the statements defined in them in code. Some people don't like
config files so first it was a way to accomodate that, but more importantly,
it was for autogenerated statements. For example, there really is no need to
have statement files when you can just ask the database for a list of stored
procedures and build them on the fly.

This release also has a tool that will generate statement files from stored
procedures or tables. Actually, your release has much of the code, but the
new release has a fairly usable tool.

--- Cory Foy <Cor...@mo...> wrote:

> Ok, second question. :)
> 
> For the stored statements, is there a way to define them all in one 
> file? Right now it seems like if I wanted to create a DataAdapter that 
> used all CRUD operations from a stored file, I'd have to have four 
> seperate files. Is there something else I'm missing?
> 
> Cory
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own 
> Applications - visit 
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel
> 

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" -
Barbara

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Snapdal-devel mailing list
Sna...@li...
https://lists.sourceforge.net/lists/listinfo/snapdal-devel

Look for a file called Statements.xml as an example. This allows all the
statments to be in a single file. In addition, you can use include statements
in Statements.xml if you want to separate them out by certain functions.

In the version I will release "real soon now" you can also specify a class that
has the statements defined in them in code. Some people don't like config files
so first it was a way to accomodate that, but more importantly, it was for
autogenerated statements. For example, there really is no need to have
statement files when you can just ask the database for a list of stored
procedures and build them on the fly.

This release also has a tool that will generate statement files from stored
procedures or tables. Actually, your release has much of the code, but the new
release has a fairly usable tool.

--- Cory Foy <Cor...@mo...> wrote:

> Ok, second question. :)
> 
> For the stored statements, is there a way to define them all in one 
> file? Right now it seems like if I wanted to create a DataAdapter that 
> used all CRUD operations from a stored file, I'd have to have four 
> seperate files. Is there something else I'm missing?
> 
> Cory
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel
> 

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Ok, second question. :)

For the stored statements, is there a way to define them all in one 
file? Right now it seems like if I wanted to create a DataAdapter that 
used all CRUD operations from a stored file, I'd have to have four 
seperate files. Is there something else I'm missing?

Cory

Philip Nelson wrote:
> PS, the provider name will be "ODBC" case sensitive if you use that config
> file.

Nevermind, the <<< ??? >>> is from the ODBC driver I'm using. I should 
have checked that before spamming the list... :)

Thanks for all the help!

Cory

Philip Nelson wrote:
> Ah, packaging error. The config file to use is actually in the SnapDAL.Test/bin
> folder. Thanks for pointing it out.

Indeed! That solved it partially. At least now I can get the DataFactory 
with "ODBC".

The other issue is with TOP statements. When I run something like 
"SELECT * FROM MyTable" it runs fine. When I change it to "SELECT TOP 1 
* FROM MyTable" I get:

System.Data.Odbc.OdbcException: ERROR [42000] SELECT TOP 1<< ??? >> 
Employee_Name FROM MASTER_PRM_EMPLOYEE
ERROR [42000] Syntax Error.

Any thoughts?

Cory

PS, the provider name will be "ODBC" case sensitive if you use that config
file.

--- Philip Nelson <pan...@ya...> wrote:

> 
> > I saw the ODBC DataFactory.config file in the src folder, but it seemed 
> > configured wrong, particularly because A) the app refused to load the 
> > System.Data.dll (hence why you saw the full path in my version), and 
> > because it had System.Data.OdbcConnection and such instead of 
> > System.Data.Odbc.OdbcConnection.
> 
> Ah, packaging error. The config file to use is actually in the
> SnapDAL.Test/bin
> folder. Thanks for pointing it out.
> 
> 
> 
> Philip - http://blogs.xcskiwinn.org/panmanphil
> "There's a difference between righteous anger and just being crabby" -
> Barbara
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel
> 

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

> I saw the ODBC DataFactory.config file in the src folder, but it seemed 
> configured wrong, particularly because A) the app refused to load the 
> System.Data.dll (hence why you saw the full path in my version), and 
> because it had System.Data.OdbcConnection and such instead of 
> System.Data.Odbc.OdbcConnection.

Ah, packaging error. The config file to use is actually in the SnapDAL.Test/bin
folder. Thanks for pointing it out.

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Philip Nelson wrote:
> Actually, the Odbc provider is built on the fly from the metadata in the
> DataFactory.config file. The class is CustomProvider and hasn't changed much in
> the last year and a half. If you can provide a failing test, I may put it in
> the suite.

Sorry, but to initialize the connection, what would I do? Something like:

SnapDAL.DataFactory dal = new SnapDAL.DataFactory(connString, "ODBC");

? Or do I use something else? It is a straight ODBC connection I'm using.

Cory

Philip Nelson wrote:
> Actually, the Odbc provider is built on the fly from the metadata in the
> DataFactory.config file. The class is CustomProvider and hasn't changed much in
> the last year and a half. If you can provide a failing test, I may put it in
> the suite.

I'll take a little closer look at that...

>  I did get your off list message and tried to write quick test to duplicate the
> problem, but was unable to do so. One of a couple of possibilities off the top
> of my head.
> 
> - something was fixed between the prerelease and my current version
> - my config file is slightly different, particularly with assembly attribute
> 
> You will also notice that I now support specifying parameter type mappings in
> the config file in case the defaults provided by System.Data aren't exactly
> what you need.

I saw the ODBC DataFactory.config file in the src folder, but it seemed 
configured wrong, particularly because A) the app refused to load the 
System.Data.dll (hence why you saw the full path in my version), and 
because it had System.Data.OdbcConnection and such instead of 
System.Data.Odbc.OdbcConnection.

What I did to work around it was modify the source to have a new 
OdbcProvider class, including changing the ProviderType enum to be aware 
of it. The OdbcProvider class was a duplicate of the OleDbProvider, 
except using only the parameter types supported by Odbc. By doing this, 
I was able to get a simple query to work, but TOP selects are failing 
for some reason.

I'll back out those changes and try using the other ways to see if I can 
get that to work. Thanks for the reply!

Cory

Actually, the Odbc provider is built on the fly from the metadata in the
DataFactory.config file. The class is CustomProvider and hasn't changed much in
the last year and a half. If you can provide a failing test, I may put it in
the suite.

 I did get your off list message and tried to write quick test to duplicate the
problem, but was unable to do so. One of a couple of possibilities off the top
of my head.

- something was fixed between the prerelease and my current version
- my config file is slightly different, particularly with assembly attribute

You will also notice that I now support specifying parameter type mappings in
the config file in case the defaults provided by System.Data aren't exactly
what you need.

<?xml version="1.0" encoding="utf-8" ?> 
<DataFactory>
  <Provider name="ODBC" assembly="System.Data">
    <Connection type="System.Data.Odbc.OdbcConnection" />
    <Command type="System.Data.Odbc.OdbcCommand" />
    <Parameter type="System.Data.Odbc.OdbcParameter" />
    <DataAdapter type="System.Data.Odbc.OdbcDataAdapter" />
    <DataReader type="System.Data.Odbc.OdbcDataReader" />
    <ParameterTypes>
	    <ParameterType name="int" enum="System.Data.Odbc.OdbcType.Int" />
	    <ParameterType name="bigint" enum="System.Data.Odbc.OdbcType.BigInt" />
	    <ParameterType name="bigint" enum="System.Data.Odbc.OdbcType.BigInt" />
	    <ParameterType name="binary" enum="System.Data.Odbc.OdbcType.Binary" />
	    <ParameterType name="bit" enum="System.Data.Odbc.OdbcType.Bit" />
	    <ParameterType name="char" enum="System.Data.Odbc.OdbcType.Char" />
	    <ParameterType name="date" enum="System.Data.Odbc.OdbcType.Date" />
	    <ParameterType name="datetime" enum="System.Data.Odbc.OdbcType.DateTime"
/>
	    <ParameterType name="decimal" enum="System.Data.Odbc.OdbcType.Decimal" />
	    <ParameterType name="double" enum="System.Data.Odbc.OdbcType.Double" />
	    <ParameterType name="image" enum="System.Data.Odbc.OdbcType.Image" />
	    <ParameterType name="nchar" enum="System.Data.Odbc.OdbcType.NChar" />
	    <ParameterType name="ntext" enum="System.Data.Odbc.OdbcType.NText" />
	    <ParameterType name="numeric" enum="System.Data.Odbc.OdbcType.Numeric" />
	    <ParameterType name="nvarchar" enum="System.Data.Odbc.OdbcType.NVarChar"
/>
	    <ParameterType name="real" enum="System.Data.Odbc.OdbcType.Real" />
	    <ParameterType name="smalldatetime"
enum="System.Data.Odbc.OdbcType.SmallDateTime" />
	    <ParameterType name="smallint" enum="System.Data.Odbc.OdbcType.SmallInt"
/>
	    <ParameterType name="text" enum="System.Data.Odbc.OdbcType.Text" />
	    <ParameterType name="time" enum="System.Data.Odbc.OdbcType.Time" />
	    <ParameterType name="timestamp" enum="System.Data.Odbc.OdbcType.Timestamp"
/>
	    <ParameterType name="tinyint" enum="System.Data.Odbc.OdbcType.TinyInt" />
	    <ParameterType name="uniqueidentifier"
enum="System.Data.Odbc.OdbcType.UniqueIdentifier" />
	    <ParameterType name="varbinary" enum="System.Data.Odbc.OdbcType.VarBinary"
/>
	    <ParameterType name="varchar" enum="System.Data.Odbc.OdbcType.VarChar" />
    </ParameterTypes>
  </Provider>
</DataFactory>

If this doesn't work for you, get back to the list and it'll prompt me to
release the beta I've been sitting on for almost a month now.

--- Cory Foy <Cor...@mo...> wrote:

> Hi All,
> 
> I don't know if anyone is still checking this list - but if so, has 
> anyone written the Odbc provider for SnapDAL? I've got it partially 
> working now, but if someone has it already completed that would be 
> excellent. Thanks!
> 
> Cory
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel
> 

Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Hi All,

I don't know if anyone is still checking this list - but if so, has 
anyone written the Odbc provider for SnapDAL? I've got it partially 
working now, but if someone has it already completed that would be 
excellent. Thanks!

Cory

--- Barry Sirote <ba...@si...> wrote:

> Phil,
> I will definitely check out the code in detail in the upcoming weeks - a
> few questions off-the-cuff however:
> 
> 1.  Is this a drop-in replacement for the vb.net version.  Meaning, does
> it use the same signatures, etc... So that, theoretically, I could
> replace the vb.net version w/o needing to do anything?

We are a year from having actually made the switch, and it's not impossible
that there was a change somewhere, but I believe this to be a drop in
replacement. 

> 
> 2.  What route did you end up taking with error handling and messages to
> that effect?

Ah yes, this has not changed. In your case you may need to change the code to
raise an event or supply a delegate for error handling, but as all of the error
handling now is directed through the DataFactory's error handler, this should
be pretty easy. If you would change it so that the default would be to use the
built in handler, but that a different one could be plugged in, I would
incorporate this change into SnapDAL.

> 
> 3.  What the heck is a mock object?

;-)

It's a big topic, but for purposes of SnapDAL its a stub on steroids. It's a
stub for the underlying IDbCommand in that no call will actually be made to the
database. It receives the parameters, transactions, etc. and if you desire will
return a reader, datatable etc to the caller. When done, you can call the
command and ask it to "Verify" that it received the correct input. In this way
you are just testing your code, not the code and the database call. Your test
code would look like (psuedocode only)

mockCommand.SetExpectedExecuteCalls(1);
mockCommand.SetExpectedTransaction(trans);
mockParm1.SetExpectedValue("atest");

//run your test... 

mockCommand.Verify();
mockParm1.Verify();

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Phil,
I will definitely check out the code in detail in the upcoming weeks - a
few questions off-the-cuff however:

1.  Is this a drop-in replacement for the vb.net version.  Meaning, does
it use the same signatures, etc... So that, theoretically, I could
replace the vb.net version w/o needing to do anything?

2.  What route did you end up taking with error handling and messages to
that effect?

3.  What the heck is a mock object?

Thanks,
Barry

-----Original Message-----
From: sna...@li...
[mailto:sna...@li...] On Behalf Of Philip
Nelson
Sent: Wednesday, December 15, 2004 12:11 AM
To: sna...@li...
Subject: [snapdal-devel] c# version has been released!

Well, enough is enough, it was time to get this out in the public. Here
is the
list of changes.

- completely rewritten in c#. The vb version will not be maintained 
  unless a volunteer steps up.
- Added .Net Mock Objects (.71) to the core making mock object
techniques
  a first class operation with SnapDAL.
- Major refactoring so that the DataFactory now uses the object factory
  services of the Provider instead of using it's own techniques
- Enhanced statement generation for SqlClient that includes gereration
  of statements for Tables as well as Stored Procedures
- Recording of test data supported for query calls that will build
  MockDataReaders from the saved data
- Very fast, almost indistinquishable from stock SqlCommand calls
- Much better documentation
- A much larger and better thought out unit test suite

I would like to thank the other developers who helped out in building
the base
of the code. Chad has been around since the start of the project and we
have
had a lot of talks over the last couple of years about how to best build
and
use a tool like SnapDAL. Chris is new but already has good ideas. 

Scott was particularly helpful in the major refactoring of the
underlying
StatementManager and caching techniques, and helped me to finally see a
more
cohesive API. I think the basic structure will hold up for good now and
we can
focus on new features.

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" -
Barbara

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Snapdal-devel mailing list
Sna...@li...
https://lists.sourceforge.net/lists/listinfo/snapdal-devel

Well, enough is enough, it was time to get this out in the public. Here is the
list of changes.

- completely rewritten in c#. The vb version will not be maintained 
  unless a volunteer steps up.
- Added .Net Mock Objects (.71) to the core making mock object techniques
  a first class operation with SnapDAL.
- Major refactoring so that the DataFactory now uses the object factory
  services of the Provider instead of using it's own techniques
- Enhanced statement generation for SqlClient that includes gereration
  of statements for Tables as well as Stored Procedures
- Recording of test data supported for query calls that will build
  MockDataReaders from the saved data
- Very fast, almost indistinquishable from stock SqlCommand calls
- Much better documentation
- A much larger and better thought out unit test suite

I would like to thank the other developers who helped out in building the base
of the code. Chad has been around since the start of the project and we have
had a lot of talks over the last couple of years about how to best build and
use a tool like SnapDAL. Chris is new but already has good ideas. 

Scott was particularly helpful in the major refactoring of the underlying
StatementManager and caching techniques, and helped me to finally see a more
cohesive API. I think the basic structure will hold up for good now and we can
focus on new features.

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.

With many thanks for your participation,
Benno Luthiger

PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________
--- "Chad M. Gross" <cg...@ne...> wrote:
> I would recommend keeping any important info out of the Message property.
> And certainly, you would always want to include the actual exception as the
> inner.  Any important info, such as CC# in the current statment's
> parameters, can be exposed through a collection off of the new typed
> exception.  As you mentioned, it would then be the developers choice to log
> the exception as they choose either "dumping" the parameters or not.  

I do like this approach. Would it make sense to have a Formatted Message
property that makes it easier to just log a complete message?

> Some
> things I can think of that may be a good idea with the DAL exceptions would
> be obviously have some SnapDALDataException base class that has props like
> StatementName and Parameters.  Then having exceptions like
> SnapDALUniqueViolationException (caused by constraint or unique index and
> try to extract the constraint/index name), SnapDALDeadlockException,
> SnapDALTimeoutException, SnapDALConfigFileNotFound, and any other common
> data provider errors or meaningful "throw new Exception()" calls that are in
> SnapDal that should be a typed exception.

One of the things I noticed while diving into this part of ADO.Net was that
exceptions aren't defined as part of the framework. If you were to truly have
generic data access, which SnapDAL now makes more possible with it's cache
directory structure, you would still be stuck with the lowest common
denominator of Exception, or in our case DataFactoryException. With a
reasonable hierarchy of typed exceptions for the most common sql errors,
timeout, deadlock, constraint, you could handle these in a consistent way.
There would be a burden to add new providers because for each we would have to
figure what native exceptions matched these generic types, but it wouldn't be
so bad.

I would like to do a release before getting started on this, because I would
like to get more feedback on the mock object implementation and see if others
will find it useful.

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

I would recommend keeping any important info out of the Message property.
And certainly, you would always want to include the actual exception as the
inner.  Any important info, such as CC# in the current statment's
parameters, can be exposed through a collection off of the new typed
exception.  As you mentioned, it would then be the developers choice to log
the exception as they choose either "dumping" the parameters or not.  Some
things I can think of that may be a good idea with the DAL exceptions would
be obviously have some SnapDALDataException base class that has props like
StatementName and Parameters.  Then having exceptions like
SnapDALUniqueViolationException (caused by constraint or unique index and
try to extract the constraint/index name), SnapDALDeadlockException,
SnapDALTimeoutException, SnapDALConfigFileNotFound, and any other common
data provider errors or meaningful "throw new Exception()" calls that are in
SnapDal that should be a typed exception.

Chad

----- Original Message ----- 
From: "Scott Hernandez" <sk...@eo...>
To: "snapdal" <sna...@li...>
Sent: Tuesday, April 27, 2004 4:07 PM
Subject: Re: [snapdal-devel] Sql and parameters in the exception message

>
> It seems like exceptions from snapdal should be as comprehensive as
> possible. Isn't one solution to just have snapdal relate exceptions by
> nesting the original exception. Snapdal doesn't need to replace the
> underlying exception, and strip the real information, it can just wrap it.
>
> Also, since no end user will directly interact with the snapdal library
(the
> library will be used by other applications) it is the developers (of the
end
> user application) responsibility to keep sensitive information from the
end
> user.
>
> ----- Original Message ----- 
> From: "Philip Nelson" <pan...@ya...>
> > I got an extensive update to the vb version of SnapDAL from Barry
Sirote.
> Most
> > of the updates are nice simple things that make sense to incorporate
into
> the
> > c# version. What constitues the greatest change though is much more
> detailed
> > exception messages.
> >
> > There is no question that detailed messages aid in troubleshooting
> problems. My
> > only reservation is that some naive implementations will show the full
> text of
> > an exception to end users, and this could expose application details
that
> > shouldn't be exposed. You may expose a user's clear text password to a
> system
> > operator, or credit card numbers could get logged to a text file that
> support
> > personnel might have access to.
> >
> > On the other hand, these very details could make helping a problem one
of
> these
> > end users has much easier to solve. You could also argue that any
message
> > included in an exception exposes to much program detail, so what's the
> > difference.  As long as you don't include system passwords, you would
> probably
> > be better off.
> >
> > I'm torn, what do you all think?  I'm all for helping debug problems,
and
> all
> > for hiding details as much as possible from the outside. Perhaps
> properties of
> > the exception that expose these things, but not the Message?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel

It seems like exceptions from snapdal should be as comprehensive as
possible. Isn't one solution to just have snapdal relate exceptions by
nesting the original exception. Snapdal doesn't need to replace the
underlying exception, and strip the real information, it can just wrap it.

Also, since no end user will directly interact with the snapdal library (the
library will be used by other applications) it is the developers (of the end
user application) responsibility to keep sensitive information from the end
user.

----- Original Message ----- 
From: "Philip Nelson" <pan...@ya...>
> I got an extensive update to the vb version of SnapDAL from Barry Sirote.
Most
> of the updates are nice simple things that make sense to incorporate into
the
> c# version. What constitues the greatest change though is much more
detailed
> exception messages.
>
> There is no question that detailed messages aid in troubleshooting
problems. My
> only reservation is that some naive implementations will show the full
text of
> an exception to end users, and this could expose application details that
> shouldn't be exposed. You may expose a user's clear text password to a
system
> operator, or credit card numbers could get logged to a text file that
support
> personnel might have access to.
>
> On the other hand, these very details could make helping a problem one of
these
> end users has much easier to solve. You could also argue that any message
> included in an exception exposes to much program detail, so what's the
> difference.  As long as you don't include system passwords, you would
probably
> be better off.
>
> I'm torn, what do you all think?  I'm all for helping debug problems, and
all
> for hiding details as much as possible from the outside. Perhaps
properties of
> the exception that expose these things, but not the Message?

I got an extensive update to the vb version of SnapDAL from Barry Sirote. Most
of the updates are nice simple things that make sense to incorporate into the
c# version. What constitues the greatest change though is much more detailed
exception messages. 

There is no question that detailed messages aid in troubleshooting problems. My
only reservation is that some naive implementations will show the full text of
an exception to end users, and this could expose application details that
shouldn't be exposed. You may expose a user's clear text password to a system
operator, or credit card numbers could get logged to a text file that support
personnel might have access to.

On the other hand, these very details could make helping a problem one of these
end users has much easier to solve. You could also argue that any message
included in an exception exposes to much program detail, so what's the
difference.  As long as you don't include system passwords, you would probably
be better off. 

I'm torn, what do you all think?  I'm all for helping debug problems, and all
for hiding details as much as possible from the outside. Perhaps properties of
the exception that expose these things, but not the Message?

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

The archives are not working for the list. According to the admin status page,
these are expected to back online sometime today. The problem with a new
subscriber not being able to send messages to the list is still unclear. The
persons name wasn't in the subscription list so that may be a different bug.
I'll keep you informed as Sourceforge works through these issues.

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

--- "Chad M. Gross" <cg...@ne...> wrote:
> Is the SnapDAL still under development?

You bet, though admitedly a bit slow. I have a c# version that I am wrestling
into something a bit nicer with the intention of allowing more than one
ProviderFactory at a time.  This would allow some nifty features like plugging
in mock objects for unit testing, plugging in a capture utitlity, again to help
with unit testing. It also would help in cases where you want to spread queries
across multiple dbs, or against multiple data sources of different types. These
last statements are honestly unproven in practice, but the architecture I'm
working on would allow this sort of thing.

=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara

Is the SnapDAL still under development?
While working on the c# version of the code, I realized that DataFactory, as
originally written by Dan Fox, doesn't actually use ProviderFactory in setting
up commands, parameters and the like. The reason appears to be the enums of
DbTypes vs SqlTypes vs OleDbTypes used in the paramters.  I think this needs to
be changed, but it will probably require scrapping some signatures of the
current ProviderFactory.

Any comments?

=====
Philip
"There's a difference between righteous anger and just being crabby" - Barbara
http://blogs.xcskiwinn.org/panmanphil

2003	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan (1)	Feb (1)	Mar (4)	Apr (4)	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec (3)
2005	Jan	Feb	Mar	Apr	May	Jun (12)	Jul	Aug	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

snapdal-devel Mailing List for SnapDAL for .Net

snapdal-devel — discuss development tasks and issues