I know this is vague but would appreciate any general advice to give me a 
quick start...
I'm new to c# and new to databases.
I want to create two tables, tblBidders, tblProjects
tblBidders will list companies
tblProjects will list projects
one view would show projects
    pick project and see list of all bidders
other view would show bidders
    pick bidder and see list of all projects bidding on

any tips for easiest place to start?
eg which control to show datatable on form
would wpf or winform be better/easier ?
sqlite or ado.net
etc

thanks
mark 

On Dec 19, 4:19=A0pm, "mp" <nos...@Thanks.com> wrote:
> I know this is vague but would appreciate any general advice to give me a
> quick start...
> I'm new to c# and new to databases.
> I want to create two tables, tblBidders, tblProjects
> tblBidders will list companies
> tblProjects will list projects
> one view would show projects
> =A0 =A0 pick project and see list of all bidders
> other view would show bidders
> =A0 =A0 pick bidder and see list of all projects bidding on
>
> any tips for easiest place to start?
> eg which control to show datatable on form
> would wpf or winform be better/easier ?
> sqlite or ado.net
> etc
>
> thanks
> mark

You want an honest answer?  You will not hear this from the SQL crowd,
and yes I do program in ADO.NET, but the easiest, fastest and for you
the best way is to forget databases entirely, and go the XML route.
Simply put your data into an XML file, and read/write from it.  You
can use XML as a source for listboxes, comboboxes, etc.  Once you
populate your list box, you can sort too (built into listboxes).  If
you program in WPF it's just like a database for most people.  BTW
your idea of a 'database' is probably not a real database.  A real
database is normalized according to Cobb's rules, with cryptic and non-
redudant info (typically you cannot make head or tails out of the raw
data in a true database, it's so broken up and atomized) and believe
you me, unless you want to take a time out of at least 6 months to
learn that stuff (like I did), you don't want to go down that road.
XML it. A book by Bipin Joshi is decent on XML, but any textbook tells
you about XML.  Also you'll use LINQ over SQL commands, which are
easier to learn.  If you insist on databases only buy the books by
Sceppa--the rest are trash.

Caveat emptor.  You might get answers from Peter and others here who
think I am a troll and that might lead you astray--don't listen to
them.  You've been warned.  If you do want to learn about databases
that's fine, but like I say it won't really solve most of your
problems.  I routinely use XML even though I'm pretty good by now
using SQL (and SQL commands, rather than LINQ).

RL

On 12/20/2009 8:54 AM, RayLopez99 wrote:
> On Dec 19, 4:19 pm, "mp"<nos...@Thanks.com>  wrote:
>> I know this is vague but would appreciate any general advice to give me a
>> quick start...
>> I'm new to c# and new to databases.
>> I want to create two tables, tblBidders, tblProjects
>> tblBidders will list companies
>> tblProjects will list projects
>> one view would show projects
>>      pick project and see list of all bidders
>> other view would show bidders
>>      pick bidder and see list of all projects bidding on
>>
>> any tips for easiest place to start?
>> eg which control to show datatable on form
>> would wpf or winform be better/easier ?
>> sqlite or ado.net
>> etc
>>
>> thanks
>> mark
>
> You want an honest answer?  You will not hear this from the SQL crowd,
> and yes I do program in ADO.NET, but the easiest, fastest and for you
> the best way is to forget databases entirely, and go the XML route.
> Simply put your data into an XML file, and read/write from it.  You
> can use XML as a source for listboxes, comboboxes, etc.  Once you
> populate your list box, you can sort too (built into listboxes).  If
> you program in WPF it's just like a database for most people.  BTW
> your idea of a 'database' is probably not a real database.  A real
> database is normalized according to Cobb's rules, with cryptic and non-
> redudant info (typically you cannot make head or tails out of the raw
> data in a true database, it's so broken up and atomized) and believe
> you me, unless you want to take a time out of at least 6 months to
> learn that stuff (like I did), you don't want to go down that road.
> XML it. A book by Bipin Joshi is decent on XML, but any textbook tells
> you about XML.  Also you'll use LINQ over SQL commands, which are
> easier to learn.  If you insist on databases only buy the books by
> Sceppa--the rest are trash.
>
> Caveat emptor.  You might get answers from Peter and others here who
> think I am a troll and that might lead you astray--don't listen to
> them.  You've been warned.  If you do want to learn about databases
> that's fine, but like I say it won't really solve most of your
> problems.  I routinely use XML even though I'm pretty good by now
> using SQL (and SQL commands, rather than LINQ).
>
> RL

For a previous discussion _opposed_ to this line of reasoning, please see:

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/a184510b20bec196


-- 
Mike

On 12/19/2009 4:19 PM, mp wrote:
> I know this is vague but would appreciate any general advice to give me a
> quick start...
> I'm new to c# and new to databases.
> I want to create two tables, tblBidders, tblProjects
> tblBidders will list companies
> tblProjects will list projects
> one view would show projects
>      pick project and see list of all bidders
> other view would show bidders
>      pick bidder and see list of all projects bidding on
>
> any tips for easiest place to start?
> eg which control to show datatable on form
> would wpf or winform be better/easier ?
> sqlite or ado.net
> etc
>
> thanks
> mark
>
>

I would start by following some of the MSDN walkthroughs, just google 
"Sql Compact CSharp Walkthrough".  The question of WPF versus winform, 
does not really come into play just because your app is database driven. 
  More examples are available for Winforms, and frankly, in my opinion, 
it's easier to understand than WPF.

Most all controls can bind to data sources, so the control choice really 
depends on the purpose in the app.  If showing an entire table, then 
perhaps the datagridview.  If showing a choice from all unique values, 
then perhaps a combobox.

-- 
Mike

RayLopez99 wrote:
> On Dec 19, 4:19 pm, "mp" <nos...@Thanks.com> wrote:
>> I know this is vague but would appreciate any general advice to give me a
>> quick start...
>> I'm new to c# and new to databases.
>> I want to create two tables, tblBidders, tblProjects
>> tblBidders will list companies
>> tblProjects will list projects
>> one view would show projects
>>     pick project and see list of all bidders
>> other view would show bidders
>>     pick bidder and see list of all projects bidding on
>>
>> any tips for easiest place to start?
>> eg which control to show datatable on form
>> would wpf or winform be better/easier ?
>> sqlite or ado.net
>> etc
>>
>> thanks
>> mark
> 
> You want an honest answer? [snip rambling...]
> 
> RL

Bloated, over-generalized reply.

Short version:

"I have a brand new XML hammer and the
world is now an XML nail."

"RayLopez99" <raylopez88@gmail.com> wrote in message 
news:a1f6c95a-b497-44e9-85c6-97ecab8855ff@s31g2000yqs.googlegroups.com...

> You want an honest answer?  You will not hear this from the SQL crowd,
> and yes I do program in ADO.NET, but the easiest, fastest and for you
> the best way is to forget databases entirely, and go the XML route.
> Simply put your data into an XML file, and read/write from it.

To the OP: ignore this post completely.

Using XML as a database is *ALWAYS* the wrong answer, simply because XML 
isn't a database.


-- 
Mark Rae
ASP.NET MVP
http://www.markrae.net 

"mp" <nospam@Thanks.com> wrote in message 
news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...

>I know this is vague but would appreciate any general advice to give me a 
>quick start...

http://www.google.co.uk/search?rlz=1C1CHMA_en-GBGB328GB328&aq=f&sourceid=chrome&ie=UTF-8&q=%22c%23%22+database+tutorial


-- 
Mark Rae
ASP.NET MVP
http://www.markrae.net 

On 20-12-2009 08:54, RayLopez99 wrote:
> On Dec 19, 4:19 pm, "mp"<nos...@Thanks.com>  wrote:
>> I know this is vague but would appreciate any general advice to give me a
>> quick start...
>> I'm new to c# and new to databases.
>> I want to create two tables, tblBidders, tblProjects
>> tblBidders will list companies
>> tblProjects will list projects
>> one view would show projects
>>      pick project and see list of all bidders
>> other view would show bidders
>>      pick bidder and see list of all projects bidding on
>>
>> any tips for easiest place to start?
>> eg which control to show datatable on form
>> would wpf or winform be better/easier ?
>> sqlite or ado.net

> You want an honest answer?  You will not hear this from the SQL crowd,
> and yes I do program in ADO.NET, but the easiest, fastest and for you
> the best way is to forget databases entirely, and go the XML route.
> Simply put your data into an XML file, and read/write from it.

Using XML for a database that need to be updated is usually not
a good approach, because it raises a lot of concurrency issues, that
the database software solved for you.

>                                                           BTW
> your idea of a 'database' is probably not a real database.  A real
> database is normalized according to Cobb's rules,

Cobb ????

Codd maybe ?

>                                                  with cryptic and non-
> redudant info (typically you cannot make head or tails out of the raw
> data in a true database, it's so broken up and atomized)

Most people manage to understand normalized databases fine.

Arne

Thanks
mark

"Mark Rae [MVP]" <mark@markNOSPAMrae.net> wrote in message 
news:ugjcu4bgKHA.1540@TK2MSFTNGP06.phx.gbl...
> "mp" <nospam@Thanks.com> wrote in message 
> news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...
>
>>I know this is vague but would appreciate any general advice to give me a 
>>quick start...
>
> http://www.google.co.uk/search?rlz=1C1CHMA_en-GBGB328GB328&aq=f&sourceid=chrome&ie=UTF-8&q=%22c%23%22+database+tutorial
>
>
> -- 
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net 

Thanks
mark

"Family Tree Mike" <FamilyTreeMike@ThisOldHouse.com> wrote in message 
news:ONsRfBZgKHA.2104@TK2MSFTNGP05.phx.gbl...
> On 12/19/2009 4:19 PM, mp wrote:
>> I know this is vague but would appreciate any general advice to give me a
>> quick start...
>> I'm new to c# and new to databases.
>> I want to create two tables, tblBidders, tblProjects
>> tblBidders will list companies
>> tblProjects will list projects
>> one view would show projects
>>      pick project and see list of all bidders
>> other view would show bidders
>>      pick bidder and see list of all projects bidding on
>>
>> any tips for easiest place to start?
>> eg which control to show datatable on form
>> would wpf or winform be better/easier ?
>> sqlite or ado.net
>> etc
>>
>> thanks
>> mark
>>
>>
>
> I would start by following some of the MSDN walkthroughs, just google "Sql 
> Compact CSharp Walkthrough".  The question of WPF versus winform, does not 
> really come into play just because your app is database driven. More 
> examples are available for Winforms, and frankly, in my opinion, it's 
> easier to understand than WPF.
>
> Most all controls can bind to data sources, so the control choice really 
> depends on the purpose in the app.  If showing an entire table, then 
> perhaps the datagridview.  If showing a choice from all unique values, 
> then perhaps a combobox.
>
> -- 
> Mike 

On Dec 20, 4:55=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:

> Most people manage to understand normalized databases fine.
>
> Arne

But don't forget, who said this below? And reread the OP carefully.
That guy not say he would be reading and writing at the same time.  He
might think he wants to do that, but 99.9% of the time people use
databases for read only.  I rest my case Arne.

RL

If your data is readonly data, then your XML files will work fine.
But if you need to update data, then supporting multiple concurrent
updates to files and recovery if somethings crashes in the middle
will be a lot of work with file and a piece of cake with
database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
FILE A PROBLEM?--RL]

Performance wise XML files will probably perform similar to database
tables without indexes. Which is OK for the data size you list. But
I am a bit skeptical about whether you really know that data would
never grow bigger.

On 12/22/2009 4:12 PM, RayLopez99 wrote:
> On Dec 20, 4:55 pm, Arne Vajh�j<a...@vajhoej.dk>  wrote:
>
>> Most people manage to understand normalized databases fine.
>>
>> Arne
>
> But don't forget, who said this below? And reread the OP carefully.
> That guy not say he would be reading and writing at the same time.  He
> might think he wants to do that, but 99.9% of the time people use
> databases for read only.  I rest my case Arne.
>
> RL
>
> If your data is readonly data, then your XML files will work fine.
> But if you need to update data, then supporting multiple concurrent
> updates to files and recovery if somethings crashes in the middle
> will be a lot of work with file and a piece of cake with
> database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
> FILE A PROBLEM?--RL]

Updating, means writing, not reading.  A crash during that is very bad...

-- 
Mike

On Dec 22, 6:41=A0pm, Family Tree Mike <FamilyTreeM...@ThisOldHouse.com>
wrote:

> > database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
> > FILE A PROBLEM?--RL]
>
> Updating, means writing, not reading. =A0A crash during that is very bad.=
...
>

True enough I suppos, but I've used XML extensively (outside a DB
context) and I think a crash in the middle of a update (write) would
be rare.  And I'm not sure that a crash in the middle of an UPDATE in
a DB (at the server end) would not corrupt the DB as well.

BTW, in Silverlight, SQL is not supported (as of yet) so that' s
another reason to use XML.

RL

Start with MS SQL Server Developer (to have all the required tools).

Create a table Bidders (forget the prefixing, instead, use the plural for a 
table, singular for fields) with at least, one field, bidder name, or bidder 
id, and other fields as what belong to the said bidder, independently of any 
project (such as address, phone, ... ).

Create your table Projects, with only data that occurs once for the project 
(such as its name, where it is, when it is due to start, etc.) independently 
of any bidder.

Create a table ProjectsBidders, two fields, the project name (or project id) 
and bidder name (or bidder id). Have ONE row for each different couple (ie. 
a project can have many bidders and a bidder can bid on many projects).


Fill your tables with data. You can add relations between the tables if you 
want, but that is not strictly required for the demo (it would, for 
integrity, though).


Now, in C#. Create  new item, a "LINQ to SQL Classes" item (be sure to have 
your application targeting .Net Framework 3.5). It is mostly graphical, as 
it would be in Office-MS Access for a relationship windows: bring the three 
tables discussed here up. That's all, for the ties to the db at least.


In code (for a windows form), create an object of the LINQ to SQL class (it 
is often called a 'context' in the literature), and use LINQ over it, like:


=================
myNameSpace.MyLINQtoSQLclass dbContext = new myNameSpace.MyLINQtoSQLclass( ) 
;

     //  the LINQ to SQL class often remove the plural for you
var myQuery = from j in dbContext.ProjectsBidder
    where j.BidderID == "Acme"
    select j.ProjectID  ;


datagridView1.DataSource = myQuery ;
=================

and this is all the database- relevant (1) code you need to display, in the 
datagridView1, all the projects where the bidder is "Acme". Replace the hard 
coded constant "Acme" by a control supplying this value, to make it more 
versatile, but I don't want to obscure the code... it is, basically, as 
simple as that!


And not very hard, isn't it?

Almost as easy as using Office-MS Access


Vanderghast, Access MVP

--------------------
(1)  while it is not the WHOLE code you need to be able to run an example, 
because that would include the MyLINQtoSQLclass object too, and the code 
for the form, but those line of codes are automatically supplied for you by 
VS2008.






"mp" <nospam@Thanks.com> wrote in message 
news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...
>I know this is vague but would appreciate any general advice to give me a 
>quick start...
> I'm new to c# and new to databases.
> I want to create two tables, tblBidders, tblProjects
> tblBidders will list companies
> tblProjects will list projects
> one view would show projects
>    pick project and see list of all bidders
> other view would show bidders
>    pick bidder and see list of all projects bidding on
>
> any tips for easiest place to start?
> eg which control to show datatable on form
> would wpf or winform be better/easier ?
> sqlite or ado.net
> etc
>
> thanks
> mark
> 

A crash, even a power failure, won't corrupt a db like MS SQL Server, 
because the pending operation would be in the log, NOT in the db itself. It 
would be, in the end, like rolling back a transaction.

MS SQL supports output in XML, so I really fail to see your point, about 
Silverlight.


It would be fine to mention that the job could be done in XML under some 
circumstances, and on that, I would have nothing to say, but to make general 
claim about something you don't know is impertinent and a blow to your 
credibility, by none other than yourself, imho.

Vanderghast, Access MVP


"RayLopez99" <raylopez88@gmail.com> wrote in message 
news:3574eff2-76fc-4816-a055-fdf87046e24d@m25g2000yqc.googlegroups.com...
On Dec 22, 6:41 pm, Family Tree Mike <FamilyTreeM...@ThisOldHouse.com>
wrote:

> > database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
> > FILE A PROBLEM?--RL]
>
> Updating, means writing, not reading. A crash during that is very bad...
>

True enough I suppos, but I've used XML extensively (outside a DB
context) and I think a crash in the middle of a update (write) would
be rare.  And I'm not sure that a crash in the middle of an UPDATE in
a DB (at the server end) would not corrupt the DB as well.

BTW, in Silverlight, SQL is not supported (as of yet) so that' s
another reason to use XML.

RL 

On Dec 29, 2:56=A0pm, "vanderghast" <vanderghast@com> wrote:
> A crash, even a power failure, won't corrupt a db like MS SQL Server,
> because the pending operation would be in the log, NOT in the db itself. =
It
> would be, in the end, like rolling back a transaction.
>

Thanks for pointing that out--I forgot about rollback and atomic
transactions.

> MS SQL supports output in XML, so I really fail to see your point, about
> Silverlight.

Silverlight does not support SQL at the moment--not sure about release
4, but 3 and before don't.  That's my point.

>
> It would be fine to mention that the job could be done in XML under some
> circumstances, and on that, I would have nothing to say, but to make gene=
ral
> claim about something you don't know is impertinent and a blow to your
> credibility, by none other than yourself, imho.
>

No, I have used SQL extensively.  I am proficient in it.  Not as good
as you perhaps, but I can move about in it freely.

 RL

On Thu, 31 Dec 2009 07:12:58 -0800 (PST), RayLopez99
<raylopez88@gmail.com> wrote:

>On Dec 29, 2:56�pm, "vanderghast" <vanderghast@com> wrote:
>
>> MS SQL supports output in XML, so I really fail to see your point, about
>> Silverlight.
>
>Silverlight does not support SQL at the moment--not sure about release
>4, but 3 and before don't.  That's my point.
>
There are a number of reasons why Silverlight both shouldn't and can't
directly interact with a local or remote SQL server. With some thought
and perhaps a review of what Silverlight is and how it works, many
these reasons should become obvious.

The third tutorial at silverlight.net involves accessing an SQL
database with a WCF service and LINQ.
http://silverlight.net/learn/tutorials/sqldatagrid-cs/

regards
A.G.

Thanks, will study that
mark

"vanderghast" <vanderghast@com> wrote in message 
news:3CC81349-73B1-4932-899F-9A4DE4AAACFA@microsoft.com...
> Start with MS SQL Server Developer (to have all the required tools).
>
> Create a table Bidders (forget the prefixing, instead, use the plural for 
> a table, singular for fields) with at least, one field, bidder name, or 
> bidder id, and other fields as what belong to the said bidder, 
> independently of any project (such as address, phone, ... ).
>
> Create your table Projects, with only data that occurs once for the 
> project (such as its name, where it is, when it is due to start, etc.) 
> independently of any bidder.
>
> Create a table ProjectsBidders, two fields, the project name (or project 
> id) and bidder name (or bidder id). Have ONE row for each different couple 
> (ie. a project can have many bidders and a bidder can bid on many 
> projects).
>
>
> Fill your tables with data. You can add relations between the tables if 
> you want, but that is not strictly required for the demo (it would, for 
> integrity, though).
>
>
> Now, in C#. Create  new item, a "LINQ to SQL Classes" item (be sure to 
> have your application targeting .Net Framework 3.5). It is mostly 
> graphical, as it would be in Office-MS Access for a relationship windows: 
> bring the three tables discussed here up. That's all, for the ties to the 
> db at least.
>
>
> In code (for a windows form), create an object of the LINQ to SQL class 
> (it is often called a 'context' in the literature), and use LINQ over it, 
> like:
>
>
> =================
> myNameSpace.MyLINQtoSQLclass dbContext = new 
> myNameSpace.MyLINQtoSQLclass( ) ;
>
>     //  the LINQ to SQL class often remove the plural for you
> var myQuery = from j in dbContext.ProjectsBidder
>    where j.BidderID == "Acme"
>    select j.ProjectID  ;
>
>
> datagridView1.DataSource = myQuery ;
> =================
>
> and this is all the database- relevant (1) code you need to display, in 
> the datagridView1, all the projects where the bidder is "Acme". Replace 
> the hard coded constant "Acme" by a control supplying this value, to make 
> it more versatile, but I don't want to obscure the code... it is, 
> basically, as simple as that!
>
>
> And not very hard, isn't it?
>
> Almost as easy as using Office-MS Access
>
>
> Vanderghast, Access MVP
>
> --------------------
> (1)  while it is not the WHOLE code you need to be able to run an example, 
> because that would include the MyLINQtoSQLclass object too, and the code 
> for the form, but those line of codes are automatically supplied for you 
> by VS2008.
>
>
>
>
>
>
> "mp" <nospam@Thanks.com> wrote in message 
> news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...
>>I know this is vague but would appreciate any general advice to give me a 
>>quick start...
>> I'm new to c# and new to databases.
>> I want to create two tables, tblBidders, tblProjects
>> tblBidders will list companies
>> tblProjects will list projects
>> one view would show projects
>>    pick project and see list of all bidders
>> other view would show bidders
>>    pick bidder and see list of all projects bidding on
>>
>> any tips for easiest place to start?
>> eg which control to show datatable on form
>> would wpf or winform be better/easier ?
>> sqlite or ado.net
>> etc
>>
>> thanks
>> mark
>>
> 

On Dec 31 2009, 5:12=A0pm, "mp" <nos...@Thanks.com> wrote:
> Thanks, will study that
> mark

> > "mp" <nos...@Thanks.com> wrote in message
> >news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...
> >>I know this is vague but would appreciate any general advice to give me=
 a
> >>quick start...
> >> I'm new to c# and new to databases.
> >> I want to create two tables, tblBidders, tblProjects
> >> tblBidders will list companies
> >> tblProjects will list projects
> >> one view would show projects
> >> =A0 =A0pick project and see list of all bidders
> >> other view would show bidders
> >> =A0 =A0pick bidder and see list of all projects bidding on
>
> >> any tips for easiest place to start?
> >> eg which control to show datatable on form
> >> would wpf or winform be better/easier ?
> >> sqlite or ado.net
> >> etc
>
>

Like I said, you would do better to use XML and populate a list.  XML
is a text file and much, much easier to work with, unless you want to
do 100s of users and deal with atomic transactions.

But at this point I'm sure you're committed to learning about it the
hard way...just like I did.  It's OK, as 6 months or more learning the
ins and outs of ADO.NET and SQL is not a bad investment in the long
run.

Goodbye,

RL

On Dec 31 2009, 11:16=A0am, Registered User <n4...@ix.netcom.com> wrote:

>
> The third tutorial at silverlight.net involves accessing an SQL
> database with a WCF service and LINQ.http://silverlight.net/learn/tutoria=
ls/sqldatagrid-cs/
>


Thank you.  Useful for those rare times that you want to use a SQL
database for read only operations from inside of Silverlight, using
WCF service.  I've added this to my toolbox for such rare occasions.

RL

"RayLopez99" <raylopez88@gmail.com> wrote in message 
news:ccc24903-7836-4850-bda9-271dd890fdc4@l2g2000vbg.googlegroups.com...
On Dec 31 2009, 5:12 pm, "mp" <nos...@Thanks.com> wrote:
> Thanks, will study that
> mark

> > "mp" <nos...@Thanks.com> wrote in message
> >news:e2nuqDPgKHA.2104@TK2MSFTNGP05.phx.gbl...
> >>I know this is vague but would appreciate any general advice to give me 
> >>a
> >>quick start...
> >> I'm new to c# and new to databases.
> >> I want to create two tables, tblBidders, tblProjects
> >> tblBidders will list companies
> >> tblProjects will list projects
> >> one view would show projects
> >> pick project and see list of all bidders
> >> other view would show bidders
> >> pick bidder and see list of all projects bidding on
>
> >> any tips for easiest place to start?
> >> eg which control to show datatable on form
> >> would wpf or winform be better/easier ?
> >> sqlite or ado.net
> >> etc
>
>

Like I said, you would do better to use XML and populate a list.  XML
is a text file and much, much easier to work with, unless you want to
do 100s of users and deal with atomic transactions.

But at this point I'm sure you're committed to learning about it the
hard way...just like I did.  It's OK, as 6 months or more learning the
ins and outs of ADO.NET and SQL is not a bad investment in the long
run.

Goodbye,

RL

hi ray
i'm committed to try to learn everything - but it all takes time and i'm 
slow learner...have to learn how to set up xml and some forms for the ui 
part
i understand a bit about tables and fields but nothign about how i would 
emulate that in xml...
i've read bits about xml, understand a bit about the heirarchical nature, 
but am hoping to find some actual samples to get me started...it's a long 
climb up from where i'm at :-)
i appreciate your input, and everyones...just takes me a while to research 
it all, i'll search for some close samples i can maybe tweak

seems i've seen some db samples that may have a grid like display with next 
previous buttons etc that may be a head start with the db option...
i'll see if there's anything siimilar with the xml option...
this isn't a multiuser high usage project with national security 
consequences..., just simple lookup functionality in a kind of cross 
reference two tables kind of format...

thanks
mark

On 22-12-2009 16:12, RayLopez99 wrote:
> On Dec 20, 4:55 pm, Arne Vajh�j<a...@vajhoej.dk>  wrote:
>> Most people manage to understand normalized databases fine.

> But don't forget, who said this below? And reread the OP carefully.
> That guy not say he would be reading and writing at the same time.  He
> might think he wants to do that, but 99.9% of the time people use
> databases for read only.  I rest my case Arne.

99% of database do get updated.

And a database as the one described by the original
poster certainly needs to be updated.

> If your data is readonly data, then your XML files will work fine.
> But if you need to update data, then supporting multiple concurrent
> updates to files and recovery if somethings crashes in the middle
> will be a lot of work with file and a piece of cake with
> database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
> FILE A PROBLEM?--RL]

It is not.

But it is also mentioned as a problem when *UPDATING* data, so ...

Arne

On 23-12-2009 10:03, RayLopez99 wrote:
> On Dec 22, 6:41 pm, Family Tree Mike<FamilyTreeM...@ThisOldHouse.com>
> wrote:
>>> database. [NOT TRUE--HOW IS A CRASH IN THE MIDDLE OF READING AN XML
>>> FILE A PROBLEM?--RL]
>>
>> Updating, means writing, not reading.  A crash during that is very bad...
>
> True enough I suppos, but I've used XML extensively (outside a DB
> context) and I think a crash in the middle of a update (write) would
> be rare.

If loosing data being rare is good enough, then a lot of
things is possible.

But usually people care about their data.

>        And I'm not sure that a crash in the middle of an UPDATE in
> a DB (at the server end) would not corrupt the DB as well.

The DB should recover fine (if it is a database server with a log
file - MS SQLServer, IBM DB2, Oracle DB, Sybase ASE,
MySQL with InnoDB tables, PostgreSQL etc.).

That is what databases do.

> BTW, in Silverlight, SQL is not supported (as of yet) so that' s
> another reason to use XML.

SL----web service----database

works fine.

For rather obvious reasons no one would want to do:

SL----database

Arne

On 02-01-2010 09:26, RayLopez99 wrote:
> On Dec 31 2009, 5:12 pm, "mp"<nos...@Thanks.com>  wrote:
>> Thanks, will study that
> Like I said, you would do better to use XML and populate a list.  XML
> is a text file and much, much easier to work with, unless you want to
> do 100s of users and deal with atomic transactions.

Unless he wants to do >1 user *or* updates.

Arne

On Jan 2, 8:33=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> > BTW, in Silverlight, SQL is not supported (as of yet) so that' s
> > another reason to use XML.
>
> SL----web service----database
>
> works fine.
>
> For rather obvious reasons no one would want to do:
>
> SL----database
>

That's interesting, thanks.  It explains why web services are used in
this thread tutorial by Jesse Liberty explaining SL and DBs.

RL

On Jan 3, 3:33=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> >> Updating, means writing, not reading. =A0A crash during that is very b=
ad...
>
> > True enough I suppos, but I've usedXMLextensively (outside a DB
> > context) and I think a crash in the middle of a update (write) would
> > be rare.
>
> If loosing data being rare is good enough, then a lot of
> things is possible.
>
> But usually people care about their data.
>
> > =A0 =A0 =A0 =A0And I'm not sure that a crash in the middle of an UPDATE=
 in
> > a DB (at the server end) would not corrupt the DB as well.
>
> The DB should recover fine (if it is a database server with a log
> file - MS SQLServer, IBM DB2, Oracle DB, Sybase ASE,
> MySQL with InnoDB tables, PostgreSQL etc.).
>
> That is what databases do.
>
> > BTW, in Silverlight, SQL is not supported (as of yet) so that' s
> > another reason to useXML.
>
> SL----web service----database
>
> works fine.

I bought a book by Papa called Data Driven Services for Silverlight2
that discusses setting up a web service for SL, and I was able to set
up and consume a simple web service.  Thanks to you and A.G. of this
thread.

But I stand by my statement that XML is a cheap and easy way to mimic
a database.  For example, nearly every example I see uses XML or hard
coded values, not a SQL query and a dB, to populate a list, GridView /
DataGrid, or combo box for example.

RL