Database for internet applications

I have a colleague who wants to build a web application that is expected to
have a fairly low number of web requests and have this site capture data in
a database. His heart is set upon Access as the back-end database.
Now, I'm happy to accept that Access is a great product, but I know very
little about it - I've always used SQL Server. My gut reaction is to
suggest that he uses SQL Server Express in preference to Access, but
unfortunately I don't know enough about Access to argue why it shouldn't be
used as a database behind a web application. I don't even know much about
the licensing model.
Could someone provide the details here (or persuade me otherwise)?
Thanks everyoneGriff
SQL Server 2005 Express Edition is free but limited to 4GB db size.If I
remeber well Access is limited to 2GB db size.
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl...
>I have a colleague who wants to build a web application that is expected to
>have a fairly low number of web requests and have this site capture data in
>a database. His heart is set upon Access as the back-end database.
> Now, I'm happy to accept that Access is a great product, but I know very
> little about it - I've always used SQL Server. My gut reaction is to
> suggest that he uses SQL Server Express in preference to Access, but
> unfortunately I don't know enough about Access to argue why it shouldn't
> be used as a database behind a web application. I don't even know much
> about the licensing model.
> Could someone provide the details here (or persuade me otherwise)?
> Thanks everyone
>|||On Oct 18, 6:18 pm, "Griff" <griffithsj_...@.hotmail.com> wrote:
> I have a colleague who wants to build a web application that is expected to
> have a fairly low number of web requests and have this site capture data in
> a database. His heart is set upon Access as the back-end database.
> Now, I'm happy to accept that Access is a great product, but I know very
> little about it - I've always used SQL Server. My gut reaction is to
> suggest that he uses SQL Server Express in preference to Access, but
> unfortunately I don't know enough about Access to argue why it shouldn't be
> used as a database behind a web application. I don't even know much about
> the licensing model.
Some notes here:
http://members.optushome.com.au/anandasim/asp.htm
You don't have to worry about licensing. Because when you use
Access .mdb as a back end database, you are not using an Access
license - you are using IIS + ADO/ADO.NET + mdb - Access does not even
need to be installed on the webserver.
One concern is .mdb is not 24x7 - you need to take it offline from
time to time to pack the database and back it up - on the other hand,
if you get the time slot and scheduled batch jobs running, you can
just grab the .mdb and put it in your pocket.
One thing to consider is if you are using a development IDE against
the Access .mdb will there be design time issues with controls and
connections working properly - I used to have those years ago. And Jet
is single threaded - when I had SQL that was half baked during
development, the whole web server would be unresponsive.
HTH
Ananda|||The salomic decission
Use SQL server as the datastore & msAccess as a FrontEnd for maintenance,
reports etc
For the solution you describe the only drawbacks of using Access as a
Back-end is that it has no built in maintenance plan,
must be "offline" for backup, can get corrupted.
Pieter
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl...
>I have a colleague who wants to build a web application that is expected to
>have a fairly low number of web requests and have this site capture data in
>a database. His heart is set upon Access as the back-end database.
> Now, I'm happy to accept that Access is a great product, but I know very
> little about it - I've always used SQL Server. My gut reaction is to
> suggest that he uses SQL Server Express in preference to Access, but
> unfortunately I don't know enough about Access to argue why it shouldn't
> be used as a database behind a web application. I don't even know much
> about the licensing model.
> Could someone provide the details here (or persuade me otherwise)?
> Thanks everyone
>|||There are no licensing issues with supplying data from an Access database
file to a web page.
There is some advantage in using an Access file to store the data, if you
need to enter, query, and report on the data from within Access.
It is not difficult for someone with experience in something like ASP or PHP
to design a web page where data is read from and/or written to an Access
database.
Access data is not really secure, so you need to ensure you handle the
security at another level. For example, last year I was able to download the
entire MDB from a computer hardware vendor because the database went
corrupt, and the error message showed the name and location of the file. In
this case, the db contained only information that was on the web (i.e. parts
and prices, not customers and orders) so no harm was done (though I did
notify them.)
If you just need to export the data from an Access table to a web page (e.g.
a product listing that needs to be re-exported whenever products or prices
change), you can also do that easily. Here's an example:
http://allenbrowne.com/AppOutputHtml.html
--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl...
>I have a colleague who wants to build a web application that is expected to
>have a fairly low number of web requests and have this site capture data in
>a database. His heart is set upon Access as the back-end database.
> Now, I'm happy to accept that Access is a great product, but I know very
> little about it - I've always used SQL Server. My gut reaction is to
> suggest that he uses SQL Server Express in preference to Access, but
> unfortunately I don't know enough about Access to argue why it shouldn't
> be used as a database behind a web application. I don't even know much
> about the licensing model.
> Could someone provide the details here (or persuade me otherwise)?
> Thanks everyone|||One thing about Access as far as web applications are concerned is that it
is still a file. If I happen to know the physical path where the Access
database file is stored (a vulnerability exposed can do this), I can
download the database file from the site ;-)
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl...
>I have a colleague who wants to build a web application that is expected to
>have a fairly low number of web requests and have this site capture data in
>a database. His heart is set upon Access as the back-end database.
> Now, I'm happy to accept that Access is a great product, but I know very
> little about it - I've always used SQL Server. My gut reaction is to
> suggest that he uses SQL Server Express in preference to Access, but
> unfortunately I don't know enough about Access to argue why it shouldn't
> be used as a database behind a web application. I don't even know much
> about the licensing model.
> Could someone provide the details here (or persuade me otherwise)?
> Thanks everyone
>|||Wow - thanks for all the feed-back everyone.
Another thing I've just thought of... Access didn't have the concept of
stored procedures - I don't know if the latest version now does. If not,
then it's of course more vulnerable to SQL Injection attacks.|||You can emulate stored procedures in Access but only in version 2002 and
higher altough a few claim that Access 2000 can do it too. There are some
limitations though such as no temp tables, output parameters cannot be used,
does not use the @. character
"Griff" <griffithsj_520@.hotmail.com> wrote in message
news:e%231tviXEIHA.1208@.TK2MSFTNGP03.phx.gbl...
> Wow - thanks for all the feed-back everyone.
> Another thing I've just thought of... Access didn't have the concept of
> stored procedures - I don't know if the latest version now does. If not,
> then it's of course more vulnerable to SQL Injection attacks.
>|||In article <uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl>, griffithsj_520
@.hotmail.com says...
> I'm happy to accept that Access is a great product
Access is only good for single user database tasks, it's always been
unstable for more than one user at at time.
Use one of the MSDE SQL versions or other versions for your solution and
you'll be a lot happier than using Access.
If you need reports you can use MS Access to pull them, but don't use
Access for a database.
--
Leythos
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@.rrohio.com (remove 999 for proper email address)|||Leythos wrote:
> In article <uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl>, griffithsj_520
> @.hotmail.com says...
>> I'm happy to accept that Access is a great product
> Access is only good for single user database tasks, it's always been
> unstable for more than one user at at time.
> Use one of the MSDE SQL versions or other versions for your solution and
> you'll be a lot happier than using Access.
> If you need reports you can use MS Access to pull them, but don't use
> Access for a database.
You probably missed the fact that this thread is crossposted to an
Access NG, or do you really believe what you wrote about Access?
--
Roy-Vidar|||Allen,
I took a look at your link with some interest, do you know how I can go
about doing the reverse; importing data Into Access 2007 from a webpage;
specifically Googlemaps. Here's what I want to do:
I want to click on an address filed in my Access form and take that address
to googlemaps and have it return a Latitude, longtitude. Before I continue,
let me explain that I already have a fully functioning database with a form
that does the first part succesffuly, namely sending the address (in the
correct google friendly format) to googlemaps, and the browser succesfully
finds the address, and using a combination of a single line Javascript (not
authored by me, I don't understand Java) and some cumbersome Access Sendkeys
I am able to get the Lat/Long and pasted it back into the field. This
approach has it's drawbacks, it involves Alt-tabbing two application windows
and when the net connection is busy, then the timing of the Senkeys gets out
of sequence and the whole process fails, If I increase the timings, then the
process becomes to slow. In summary, it is a bit of a Heath-Robinson setup.
So I was wondering if you could give me some pointers and an understanding
on how to go about automating the process properly. I can understand VBA to a
certain extent, but really don't know where to start. What do you think, can
it be done?
"Allen Browne" wrote:
> There are no licensing issues with supplying data from an Access database
> file to a web page.
> There is some advantage in using an Access file to store the data, if you
> need to enter, query, and report on the data from within Access.
> It is not difficult for someone with experience in something like ASP or PHP
> to design a web page where data is read from and/or written to an Access
> database.
> Access data is not really secure, so you need to ensure you handle the
> security at another level. For example, last year I was able to download the
> entire MDB from a computer hardware vendor because the database went
> corrupt, and the error message showed the name and location of the file. In
> this case, the db contained only information that was on the web (i.e. parts
> and prices, not customers and orders) so no harm was done (though I did
> notify them.)
> If you just need to export the data from an Access table to a web page (e.g.
> a product listing that needs to be re-exported whenever products or prices
> change), you can also do that easily. Here's an example:
> http://allenbrowne.com/AppOutputHtml.html
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
> "Griff" <griffithsj_520@.hotmail.com> wrote in message
> news:uqkH79VEIHA.4748@.TK2MSFTNGP06.phx.gbl...
> >I have a colleague who wants to build a web application that is expected to
> >have a fairly low number of web requests and have this site capture data in
> >a database. His heart is set upon Access as the back-end database.
> >
> > Now, I'm happy to accept that Access is a great product, but I know very
> > little about it - I've always used SQL Server. My gut reaction is to
> > suggest that he uses SQL Server Express in preference to Access, but
> > unfortunately I don't know enough about Access to argue why it shouldn't
> > be used as a database behind a web application. I don't even know much
> > about the licensing model.
> >
> > Could someone provide the details here (or persuade me otherwise)?
> >
> > Thanks everyone
>

Database Field showing as zero in report footer but works in group footer

I'm fairly new to crystal so there may be an obvious solution but I just can't find it. So any help what-so-ever would be excellent and much appreciated...

Problem:

Database field shows correct value and works in formulas properly in group footer.
In Report footer this same database field shows as zero and therefore other formulas in the report footer do not calculate correctly.

Any solutions?Please. Any help would be greatly appreciated. I'm kind of in a time crunch.

I'm not sure why a database field would show the value in the group footer and come up zero in the report footer.

Any ideas??|||Sorry, don't know why either - the report footer always shows the final database record for me!
I have read of other people having this problem, and I believe that assigning the fiele to a shared variable has allowed the value to be used.|||I gave it a variable and now it works. How weird is that?!

Thanks for your help!sql

Database Design Question

I'm fairly inexperienced when it comes to database design and programming bu
t
since our company is too cheap to hire anyone more experienced, I was hoping
someone here could help me out.
Our company assembles computers and we want to develop an order processing
system, so here is the set up.
Each order can have many computers.
Each computer is made up of many components (CPU, Motherboard, RAM, etc.)
Each component has many properties (Brand Name, Speed, Capacity, etc.)
So I want to know the best way of setting up my tables.
Just looking at the computer table, the first way I considered was for each
computer would take up one row and all its components would take up the
columns. For Example:
SerialNumber - CPU - Motherboard - Memory - Harddrive - CDRW - etc.,
111111 - P4 - ASUS - 512 - WD80 - LG CDRW - etc.,
222222 - Athlon 64 - Gigabyte - 1GB - Maxtor 80GB - BenQ DVD RW - etc.,
You can see the problem. I have no idea how many columns I'll need because a
computer can have only a few components or dozens including multiple drives,
graphics cards, memory sticks, and so on.
The second way I considered was instead of having everything on a horizontal
line, to make it vertical. So my columns would be SerialNumber,
ComponentType, ComponentName. And that would look like this.
SerialNumber - ComponentType - ComponentName
111111 - CPU - P4
111111 - MotherBoard - ASUS
111111 - Memory - Kingston 512MB
... etc...
222222 - CPU - Athlon 64
222222 - MotherBoard - Gigabyte
222222 - Memory - Corsair 1GB
... etc...
That's certainly much more flexible in terms of adding components to a
computer, but I'm worried about how big the table might get. For example, if
we get orders for 500,000 computers, each with 10 - 15 components, that's
over 5 million rows. I've never dealt with large databases and tables before
so is that something I should worry about or can SQL Server handle that
easily?
Or is there a different design I should consider? Any direction or links
would be appreciated.
Thanks.> Our company assembles computers and we want to develop an order processing
> system
Why? You can buy one off the shelf for much less than it will cost to
develop, especially given your inexperience.
For your info SQL Server is capable of handling tables with 100s of millions
of rows. On the other hand a poor design can fail whatever the data size.
Your second design makes far more sense but it's obvious you have a lot to
learn. I recommend you give up on developing the order processing system and
invest the time on a course instead.
David Portas
SQL Server MVP
--|||It is not clear from your question how you plan to use the information. Do
you want to track inventory? Lot/Serial information? Cost? Labor? What
documents do you need to produce? Inventory Picking sheets? Routings? Bills
of lading? Purchase Orders? Invoices?
It would probably be better to pick something off the shelf and customize it
than to roll your own.
"pete K" <peteK@.discussions.microsoft.com> wrote in message
news:9A529093-75C9-4E66-BD5B-9A0EFCCDF70E@.microsoft.com...
> I'm fairly inexperienced when it comes to database design and programming
but
> since our company is too cheap to hire anyone more experienced, I was
hoping
> someone here could help me out.
> Our company assembles computers and we want to develop an order processing
> system, so here is the set up.
> Each order can have many computers.
> Each computer is made up of many components (CPU, Motherboard, RAM, etc.)
> Each component has many properties (Brand Name, Speed, Capacity, etc.)
> So I want to know the best way of setting up my tables.
> Just looking at the computer table, the first way I considered was for
each
> computer would take up one row and all its components would take up the
> columns. For Example:
> SerialNumber - CPU - Motherboard - Memory - Harddrive - CDRW - etc.,
> 111111 - P4 - ASUS - 512 - WD80 - LG CDRW - etc.,
> 222222 - Athlon 64 - Gigabyte - 1GB - Maxtor 80GB - BenQ DVD RW - etc.,
> You can see the problem. I have no idea how many columns I'll need because
a
> computer can have only a few components or dozens including multiple
drives,
> graphics cards, memory sticks, and so on.
> The second way I considered was instead of having everything on a
horizontal
> line, to make it vertical. So my columns would be SerialNumber,
> ComponentType, ComponentName. And that would look like this.
> SerialNumber - ComponentType - ComponentName
> 111111 - CPU - P4
> 111111 - MotherBoard - ASUS
> 111111 - Memory - Kingston 512MB
> ... etc...
> 222222 - CPU - Athlon 64
> 222222 - MotherBoard - Gigabyte
> 222222 - Memory - Corsair 1GB
> ... etc...
> That's certainly much more flexible in terms of adding components to a
> computer, but I'm worried about how big the table might get. For example,
if
> we get orders for 500,000 computers, each with 10 - 15 components, that's
> over 5 million rows. I've never dealt with large databases and tables
before
> so is that something I should worry about or can SQL Server handle that
> easily?
> Or is there a different design I should consider? Any direction or links
> would be appreciated.
> Thanks.|||Personally, I agree with you and those were the same concerns I expressed to
the president of my company. But he's the type of person who, once he gets a
n
idea in his head, he can't be shaken of it, and this is one of them. So what
can I do but humour him? It's his company and if he wants to waste the time
and money on a project that is likely beyond my skill set despite my
protestations to the obviously, well, all I can do is go along with it and d
o
my best. But hey, that's life I guess.
"David Portas" wrote:

> Why? You can buy one off the shelf for much less than it will cost to
> develop, especially given your inexperience.
> For your info SQL Server is capable of handling tables with 100s of millio
ns
> of rows. On the other hand a poor design can fail whatever the data size.
> Your second design makes far more sense but it's obvious you have a lot to
> learn. I recommend you give up on developing the order processing system a
nd
> invest the time on a course instead.
> --
> David Portas
> SQL Server MVP
> --
>
>|||You should start with Database Design for Mere Mortals by Michael J.
Hernandez. Even with that start, you'll still screw things up and have
plenty of questions here, but it's a pretty good baseline to understanding
where you are headed.
I'm going to set the over/under line on this project at about 1 1/2 years or
$80,000, whichever comes first.
"pete K" <peteK@.discussions.microsoft.com> wrote in message
news:9A529093-75C9-4E66-BD5B-9A0EFCCDF70E@.microsoft.com...
> I'm fairly inexperienced when it comes to database design and programming
> but
> since our company is too cheap to hire anyone more experienced, I was
> hoping
> someone here could help me out.
> Our company assembles computers and we want to develop an order processing
> system, so here is the set up.
> Each order can have many computers.
> Each computer is made up of many components (CPU, Motherboard, RAM, etc.)
> Each component has many properties (Brand Name, Speed, Capacity, etc.)
> So I want to know the best way of setting up my tables.
> Just looking at the computer table, the first way I considered was for
> each
> computer would take up one row and all its components would take up the
> columns. For Example:
> SerialNumber - CPU - Motherboard - Memory - Harddrive - CDRW - etc.,
> 111111 - P4 - ASUS - 512 - WD80 - LG CDRW - etc.,
> 222222 - Athlon 64 - Gigabyte - 1GB - Maxtor 80GB - BenQ DVD RW - etc.,
> You can see the problem. I have no idea how many columns I'll need because
> a
> computer can have only a few components or dozens including multiple
> drives,
> graphics cards, memory sticks, and so on.
> The second way I considered was instead of having everything on a
> horizontal
> line, to make it vertical. So my columns would be SerialNumber,
> ComponentType, ComponentName. And that would look like this.
> SerialNumber - ComponentType - ComponentName
> 111111 - CPU - P4
> 111111 - MotherBoard - ASUS
> 111111 - Memory - Kingston 512MB
> ... etc...
> 222222 - CPU - Athlon 64
> 222222 - MotherBoard - Gigabyte
> 222222 - Memory - Corsair 1GB
> ... etc...
> That's certainly much more flexible in terms of adding components to a
> computer, but I'm worried about how big the table might get. For example,
> if
> we get orders for 500,000 computers, each with 10 - 15 components, that's
> over 5 million rows. I've never dealt with large databases and tables
> before
> so is that something I should worry about or can SQL Server handle that
> easily?
> Or is there a different design I should consider? Any direction or links
> would be appreciated.
> Thanks.

Database Design Question

Hi there,

I'm fairly new to database design, having only really worked with
existing tables etc in the past.

Simple question this really.........

In a users table, is it wise to have a ManagerID column that is
effectively pointing to another user in the same table, with the
theory being that if that person is top dog, they will just have a
null entry in ManagerID.

I will check for circular references before entering the data.

Is there a better way of storing the data, or is this the only way?

Thanks,
Michael.On Jun 8, 4:12 pm, Michael_Burgess <m...@.marsh-hall-studios.co.uk>
wrote:

Quote:

Originally Posted by

Hi there,
>
I'm fairly new to database design, having only really worked with
existing tables etc in the past.
>
Simple question this really.........
>
In a users table, is it wise to have a ManagerID column that is
effectively pointing to another user in the same table, with the
theory being that if that person is top dog, they will just have a
null entry in ManagerID.
>
I will check for circular references before entering the data.
>
Is there a better way of storing the data, or is this the only way?
>
Thanks,
Michael.

This is the way to store data , Otherwise you may require as many
tables as there are levels . You have to build a hierarchy column
for easy retrieval of child and parent|||I would Have A lookup Table because you may end up with a person having
more then one manager.
UserID|ManagerID
Michael_Burgess wrote:

Quote:

Originally Posted by

Hi there,
>
I'm fairly new to database design, having only really worked with
existing tables etc in the past.
>
Simple question this really.........
>
In a users table, is it wise to have a ManagerID column that is
effectively pointing to another user in the same table, with the
theory being that if that person is top dog, they will just have a
null entry in ManagerID.
>
I will check for circular references before entering the data.
>
Is there a better way of storing the data, or is this the only way?
>
Thanks,
Michael.
>

|||On Jun 8, 2:56 pm, Seribus Dragon <Seribus.n...@.seribus.comwrote:

Quote:

Originally Posted by

I would Have A lookup Table because you may end up with a person having
more then one manager.
UserID|ManagerID
>
>
>
Michael_Burgess wrote:

Quote:

Originally Posted by

Hi there,

>

Quote:

Originally Posted by

I'm fairly new to database design, having only really worked with
existing tables etc in the past.

>

Quote:

Originally Posted by

Simple question this really.........

>

Quote:

Originally Posted by

In a users table, is it wise to have a ManagerID column that is
effectively pointing to another user in the same table, with the
theory being that if that person is top dog, they will just have a
null entry in ManagerID.

>

Quote:

Originally Posted by

I will check for circular references before entering the data.

>

Quote:

Originally Posted by

Is there a better way of storing the data, or is this the only way?

>

Quote:

Originally Posted by

Thanks,
Michael.- Hide quoted text -

>
- Show quoted text -

Would you be able to give me a very trivial example with some mini-
tables at all please? Sorry to put you out.

Thanks,
Michael.|||-- try this

create table employees
(
employee_id tinyint identity(1,1) not null primary key,
employee_name [varchar](50) not null
)
go

create table management_hierarchy
(
employee_id tinyint not null,
manager_id tinyint null
)
go

-- foreign key - employee
alter table
management_hierarchy with check
add constraint fk_mh_employee foreign key(employee_id)
references employees(employee_id)
go
alter table
management_hierarchy
check constraint fk_mh_employee
go

-- foreign key - manager
alter table
management_hierarchy with check
add constraint fk_mh_manager foreign key(manager_id)
references employees(employee_id)
go
alter table
management_hierarchy
check constraint fk_mh_manager
go

-- insert sample data
insert into employees(employee_name) values ('Jason Lepack')
insert into employees(employee_name) values ('Bobsyer Uncle')
insert into employees(employee_name) values ('Sweet Lee')
go
insert into management_hierarchy(employee_id, manager_id)
values(1, null)
insert into management_hierarchy(employee_id, manager_id)
values(2,1)
insert into management_hierarchy(employee_id, manager_id)
values(3, 1)
go

-- output the data
select * from employees
go

select * from management_hierarchy

select
e.employee_name subordinate,
m.employee_name manager
from
management_hierarchy mh
inner join employees e
on e.employee_id = mh.employee_id
left join employees m
on m.employee_id = mh.manager_id
go

-- drop the tables
drop table management_hierarchy
drop table employees

On Jun 8, 10:57 am, Michael_Burgess <m...@.marsh-hall-studios.co.uk>
wrote:

Quote:

Originally Posted by

On Jun 8, 2:56 pm, Seribus Dragon <Seribus.n...@.seribus.comwrote:
>
>
>
>
>

Quote:

Originally Posted by

I would Have A lookup Table because you may end up with a person having
more then one manager.
UserID|ManagerID

>

Quote:

Originally Posted by

Michael_Burgess wrote:

Quote:

Originally Posted by

Hi there,

>

Quote:

Originally Posted by

Quote:

Originally Posted by

I'm fairly new to database design, having only really worked with
existing tables etc in the past.

>

Quote:

Originally Posted by

Quote:

Originally Posted by

Simple question this really.........

>

Quote:

Originally Posted by

Quote:

Originally Posted by

In a users table, is it wise to have a ManagerID column that is
effectively pointing to another user in the same table, with the
theory being that if that person is top dog, they will just have a
null entry in ManagerID.

>

Quote:

Originally Posted by

Quote:

Originally Posted by

I will check for circular references before entering the data.

>

Quote:

Originally Posted by

Quote:

Originally Posted by

Is there a better way of storing the data, or is this the only way?

>

Quote:

Originally Posted by

Quote:

Originally Posted by

Thanks,
Michael.- Hide quoted text -

>

Quote:

Originally Posted by

- Show quoted text -

>
Would you be able to give me a very trivial example with some mini-
tables at all please? Sorry to put you out.
>
Thanks,
Michael.- Hide quoted text -
>
- Show quoted text -

|||>Is there a better way of storing the data, or is this the only way? <<

Get a copy of TREES & HIERARCHIES IN SQL for several different ways to
do an organizational chart. What you have is teh adjacency list
model; look up the nested sets model.