[dba-VB] Scrum & C# - VS versions we have

Gustav Brock Gustav at cactus.dk
Thu Mar 12 08:29:19 CDT 2009


Hi SCRUM team

Yes, maybe the relational model of this db can cause us some headache - I remember many years ago JC ranting about this.

As for the model, I've found too, that it is preferable to make changes in the database first. However, the model in VS - the DataTables - don't get updated automatically but it is quite easy to make the same adjustments in the DataTable(Adapter)s afterwards

One tricky issue I've seen is, that for fields of AutoNumber, the properties of these sometimes are not read correctly. This means that the db can have a seed of 1 while the model in VS has a seed of 0. This, of course, creates strange errors as soon as you start adding records via the DataTable.
Also, sometimes, the property "Allow Null values" for fields are read incorrectly. But, again, this is quite easy and fast to check and correct.

That said, I haven't worked with the DataTables for any other tables than such having an Id of AutoNumber as the primary key. In fact, I've turned quite "hysterical" about this because the advantage of _always_ having this Id key is so big in general and indeed when you work with the model that there is no excuse to not do so.

In my latest app I had full control over the table schema so no problem, but for a given schema like Northwind, you have the option to name the fields in model otherwise than the related fields in the database, should you feel so. 

This is a topic for discussion.

The naming I use is extremely simple and not invented by me:

Customer
  Id
  Name
  etc.

Order
  Id
  CustomerId
  etc.

OrderLine
  Id
  OrderId
  etc.

The trick is, I've learned, that you _always_ know that Id is the primary key of the table and any other xxxxId is a foreign key, while - of course - xxxx is _always_ referring to the primary key of table xxxx and this field is named Id. Any other field must not be named to contain "Id", use anything else like Num, No, Key, Code or the like. No rocket science, I know, but I've seen some fancy naming conventions hard to remember and/or to grasp ... this method is so simple that you can't fail.

/gustav


>>> Salakhetdinov Shamil <mcp2004 at mail.ru> 12-03-2009 09:01:31 >>>

Hi SCRUM team at all,

Just added to simple sample application:

https://cid-000971dc34dc18c0.groups.skydrive.live.com/self.aspx/.Documents/NorthWind.NET/Samples/SimpleWinForm/NorthWindWinFormSample%7C_3.zip 

- NorthWindDataModelDataSet - dataset having the whole datamodel;
- ShipperOrdersForm - Parent/Child;
- CategoryProductsForm - Parent/Child, Database Image Binding.

Please note the above sample *does* intentionally/occasionally have got some issues/inconsistencies, which should be talked through/fixed in the real conversion project. For example:

1. Shipper table has ShipperId id field and Order table has ShipVia foreign key field - the latter should be better named ShipperID; 

2. Relationships in MS SQL 2005 database are not renamed manually after upsizing - thus when designing datasets relations get Order_FK1 name etc. - relations should be better renamed on the database level to have them consistently named in datasets and referred in winforms' binding...

etc.

The above issues are not critical of course but desirable(?) to be fixed...

There could be other non-critical/critical issues - please note them and propose the way(s) to solve/workaround them...

Thank you.

--
Shamil






More information about the dba-VB mailing list