The Northwind 2 Project

Status
Not open for further replies.
I can't speak for the rest of the team, but version control for a template seems well outside the scope of the project.
 
Maybe I am misunderstanding something. I was under the impression there is a team working on a project? If so, I was wondering how the team is planing on making changes without stepping on each other...
 
No it was I who misunderstood your question :rolleyes:

I was thinking you meant VC for the template once it is deployed to users. I need to stop and take a nap.

We're discussing that currently. It depends a lot on how tasks eventually get divided up.
 
Last edited:
One of the advantages of creating specs before building out the data model is that one knows what needs to be in the data model before the tables get built. As you point out, if Northwind were a direct mail marketing organization, the specs would call for a different approach to addresses.
I guess that's where this came from
"Weeks of programming can save you hours of planning"
Seems the team has the planning before coding (y)(y)
Good stuff George!
 
Its a great project and I even come across Northwind in SQL Server examples - Naming convention seems perfectly fine to me..

One thing which seems quite personal to me which might be of interest- I usually prefix my table descriptions with incremental reference t001 t002 etc.... going forward and have my primary key in every table as pkid. Any foreign keys in alternative tables are then named as pkidtablereference eg pkidt001 pkidt002 etc... I use it in SQL server as well.

I prefix my views with v001 v002 etc..

You guys are very experienced so I guess you might have come across that before. Does help me quickly put relations between tables and views and helps me write SQL queries as well.
 
Thanks for the feedback. Because Northwind is aimed at a broad audience, it's going to have more plain vanilla naming.
 
Numbers as names may work for some but I'm guessing, not very many. When a new person looks at an app that relies on numbers as names, they won't know what anything is. Yes, if they understand what you've done, they might be able to follow the connections but properly constructed names don't require this process.

I do use numbers in names but normally in queries that I use to run to do some long, complicated, multi-step process.
 
Numbers as names may work for some but I'm guessing, not very many. When a new person looks at an app that relies on numbers as names, they won't know what anything is. Yes, if they understand what you've done, they might be able to follow the connections but properly constructed names don't require this process.

I do use numbers in names but normally in queries that I use to run to do some long, complicated, multi-step process.
I'm reminded of a comment once made by a successful Access developer I know. This isn't verbatim, but it went something like this:

"If you have to distribute a user guide for other developers to make sense of your table and field names, you've gone too far."
 
I will start a list and add to it. I see this as a tutorial of what can be done in Access, not a tutorial of how to build an inventory DB.

Like to See:
1. Examples of table level triggers
2. Examples of Hierarchical data (potentially a tree view)
3. Emulated split form and standard split form
4. Multivalue field vs standard one to many
5. Examples of Many to Many tables and forms. Currently in NW 10 there is supposed to be a many to many, but it is not demoed
6. Cascading comboboxes
7. Search forms using parameterized searches and dynamic filters / sql
8 Calcualted fields and calculations in the query
9. Have messagboxes or labels describing what the form is demonstrating (Example : "This is a split form using the native split form capability")
10. Images using an image control, using externally stored images, using attachments, using OLE.


Like to not See:
1. No table lookups as seen in NW 2010
2. No stupid naming conventions
3. NO MACROS. Do a seperate database with Macros. WE ALL HATE MACROS.
 
Last edited:
I will start a list and add to it. I see this as a tutorial of what can be done in Access, not a tutorial of how to build an inventory DB.

Like to See:
1. Examples of table level triggers
2. Examples of Hierarchical data (potentially a tree view)
3. Emulated split form and standard split form
4. Multivalue field vs standard one to many
5. Examples of Many to Many tables and forms. Currently in NW 10 there is supposed to be a many to many, but it is not demoed
6. Cascading comboboxes
7. Search forms using parameterized searches and dynamic filters / sql
8 Calcualted fields and calculations in the query
9. Have messagboxes or labels describing what the form is demonstrating (Example : "This is a split form using the native split form capability")



Like to not See:
1. No table lookups as seen in NW 2010
Thanks. I'll take that to tomorrow's session.
 
Thanks. I'll take that to tomorrow's session.
If done well this could be the demonstration database for all things. I post thousands of examples of database code, if this was a good example I would always use it. But I do not use NW because it is full of things like table lookups. It would end up confusing people. If we had a really clean common db then I would think we would use it as the example db.
In my mind it would be great if this was the demo of different ways to do things. For example you could show images in attachments, ole, or external.
 
Numbers as names may work for some but I'm guessing, not very many. When a new person looks at an app that relies on numbers as names, they won't know what anything is. Yes, if they understand what you've done, they might be able to follow the connections but properly constructed names don't require this process.

I do use numbers in names but normally in queries that I use to run to do some long, complicated, multi-step process.
I should say that with my naming conventrion the number part is only a prefix a textual word description comes after my prefix... so for example t001users - anyway only personal preference. I do have to write queries against a massive oracle database at work and it can be really difficult to find what table a foreign key is related to as there are hundreds of tables and the foreign key description is rarely unique.
 
well i saw the Word doc, and Nothing is New?!
i thought that it is like a Movie, there is a Sequel and much action.
btw there is already NW2 (or 3)? they are using Adventurework?
you're version, what will you call your imaginary company and the type of business?
you should post a "sneak" preview movie or a promotional video or something similar..
an eye catching one, so people will still get curious.
 
well i saw the Word doc, and Nothing is New?!
i thought that it is like a Movie, there is a Sequel and much action.
btw there is already NW2 (or 3)? they are using Adventurework?
you're version, what will you call your imaginary company and the type of business?
you should post a "sneak" preview movie or a promotional video or something similar..
an eye catching one, so people will still get curious.
I'm not sure what makes you thing nothing is new here. The data model is different; the approach is different. There is no interface yet because that work hasn't started yet. We are soliciting specific suggestions about that. That's why the public notice here and elsewhere. It will remain "Northwind", of course, but it should ultimately be considerably different by this time next year.

That said, please provide your feedback directly to the team via the Word doc by adding your comments to it and emailing it to Tom Van Stiphout at the email address in it.

AdventureWorks actually exists -- to my knowledge -- in at least three different versions, but only as a SQL Server MDF; we've consulted it for ideas, in fact, in a team meeting. However, it is a SQL Server database and other than a similar business model, i.e. a company selling products to customers, there's not a lot of overlap. In any case, AW is an MDF and has no interface at all.

You flatter us with the suggestion we produce a movie, or even just a video. It's been a volunteer effort of a small team of people, and it will continue to be that with the addition of input and assistance from other volunteers. We need the Access community's input. However, the time and resources to produce videos and movies is simply not a luxury we have been afforded. On the other hand, if a volunteer were to step up and offer to do that with us, I'll bet it would be a welcome addition.

The link to the Word document with Tom's email address is, once again, The first draft of the Northwind2 Project Proposal.
 
I would hope that all fields in all tables have a definition/description to prevent guessing on behalf of those reviewing, learning and referencing NW2.


In the DEV version "Customers call into Northwind Traders", but Companies is the table in the model. Will Company Type differentiate Customer, Supplier, Shipper (basically Role)?


Also in DEV "if below the Reorder Level, a purchase order (PO) will be sent to a vendor." I suggest a Reorder Quantity be used on that PO.
 
keep focus on the target, "Modernizing" NW,
removing MVF, Lookup fields, then where is modern there?
you are going back to old classic.
Actually the "old" NW sample is already modern, how much modernization can you
further squeeze to it?

will we see a phone like navigation (3 dots that you can click, or swipe left to right for the next form/page)?
are we going to see a NOsql approach?
or we will just see a Re-invention of the old wheel?
 
keep focus on the target, "Modernizing" NW,
removing MVF, Lookup fields, then where is modern there?
you are going back to old classic.
Actually the "old" NW sample is already modern, how much modernization can you
further squeeze to it?

will we see a phone like navigation (3 dots that you can click, or swipe left to right for the next form/page)?
are we going to see a NOsql approach?
or we will just see a Re-invention of the old wheel?
Please feel free to use the Project Proposal Document to provide your feedback to the team.
Even better contact Tom Van Stiphout (his email is in the document) and offer to help with the project.
 
I would hope that all fields in all tables have a definition/description to prevent guessing on behalf of those reviewing, learning and referencing NW2.


In the DEV version "Customers call into Northwind Traders", but Companies is the table in the model. Will Company Type differentiate Customer, Supplier, Shipper (basically Role)?


Also in DEV "if below the Reorder Level, a purchase order (PO) will be sent to a vendor." I suggest a Reorder Quantity be used on that PO.
Keep in mind that this is the first draft of the "Proposed" project and there are some things to be settled. And, yes, one of those is the exact name there. Surprising as that may be, it is not an uncontroversial topic. :rolleyes:

That said, we are actively soliciting feedback, hence posting a link to the document here and elsewhere. The best way to get that feedback to the full team is to use the Word document by adding your comments to it and emailing it to Tom vS at the email address in the Word document.

We very much appreciate that feedback and suggestions. Not every idea can make it into the end result, of course, but the more we hear from working Access Developers, the more likely we are to hit the right notes.
 
Status
Not open for further replies.

Users who are viewing this thread

Back
Top Bottom