Linking files? 
Author Message
 Linking files?

I need some suggestions.  Here's the problem

We are trying to centralize our Products / Inventory database. It's
currently in three separate departments. It starts in Marketing where they
work only with current (still can order) and future products. They are
currently using excel. Second, Is operations in our business software
(MAS90) they only deal with in stock or backordered products. Third, we
maintain five websites, using filemaker as the front end. One of these sites
will have the same products as the marketing db. The other sites are smaller
sub sets of the operation db.  Additionally, for customer service we need to
keep records of products after they are discontinued.

Because of data integrity issues, I don't want all users in all departments
to have access to main file that will contain all products. Rather I'm
thinking I should create child files for each dept. Each one of these would
have a rel. to the master. Then they can add their own fields, create
reports, scripts etc. But never change or delete anything from the master.

Is this even a feasible way to go about this?

If so, I'm not sure how to setup the relationships, so that each child sees
only records that should be in their "universe".

TIA

Lew



Tue, 08 Feb 2005 08:09:37 GMT
 Linking files?

Sounds more like 'Department' is an attribute of an order (or PO or Invoice)
form. You can create different relationships, and present (using different
layouts) different portals to Products, each based on the Department. Or,
more likely, use filtered relationships, in which the left hand key is a
concatenation of Department and, say, an Invoice Number.

You haven't said what 'have access to' means; in other words, what are the
departments, or anyone for that matter, doing? Are they buying or selling
items in Inventory, or routing them, or...? Knowing a bit more about the end
task might help us give more useful answers.
--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance


Quote:
> I need some suggestions.  Here's the problem

> We are trying to centralize our Products / Inventory database. It's
> currently in three separate departments. It starts in Marketing where they
> work only with current (still can order) and future products. They are
> currently using excel. Second, Is operations in our business software
> (MAS90) they only deal with in stock or backordered products. Third, we
> maintain five websites, using filemaker as the front end. One of these
sites
> will have the same products as the marketing db. The other sites are
smaller
> sub sets of the operation db.  Additionally, for customer service we need
to
> keep records of products after they are discontinued.

> Because of data integrity issues, I don't want all users in all
departments
> to have access to main file that will contain all products. Rather I'm
> thinking I should create child files for each dept. Each one of these
would
> have a rel. to the master. Then they can add their own fields, create
> reports, scripts etc. But never change or delete anything from the master.

> Is this even a feasible way to go about this?

> If so, I'm not sure how to setup the relationships, so that each child
sees
> only records that should be in their "universe".

> TIA

> Lew



Tue, 08 Feb 2005 09:24:43 GMT
 Linking files?
John thank for the response. I'm not looking to track inventory Qty. or
create Invoices/POs.  I think the best way to explain what each dept will be
doing, is they will be working with founds sets.

In other words Marketing be creating price sheets based on manufacture.
Giving price quotes based on product line, manufacture and price points.

In the web dept., using ODBC we pull inventory levels from our operations
S/W. Then based on these numbers they move products off on the website.

I hope this helps. What I'm looking for is some detail on how to setup the
relationships between the Master and these child files.

Thanks again

Lew

Quote:

>Sounds more like 'Department' is an attribute of an order (or PO or
Invoice)
>form. You can create different relationships, and present (using different
>layouts) different portals to Products, each based on the Department. Or,
>more likely, use filtered relationships, in which the left hand key is a
>concatenation of Department and, say, an Invoice Number.

>You haven't said what 'have access to' means; in other words, what are the
>departments, or anyone for that matter, doing? Are they buying or selling
>items in Inventory, or routing them, or...? Knowing a bit more about the
end
>task might help us give more useful answers.
>--
>John Weinshel
>Datagrace
>Vashon Island, WA
>(206) 463-1634
>Associate Member, Filemaker Solutions Alliance



>> I need some suggestions.  Here's the problem

>> We are trying to centralize our Products / Inventory database. It's
>> currently in three separate departments. It starts in Marketing where
they
>> work only with current (still can order) and future products. They are
>> currently using excel. Second, Is operations in our business software
>> (MAS90) they only deal with in stock or backordered products. Third, we
>> maintain five websites, using filemaker as the front end. One of these
>sites
>> will have the same products as the marketing db. The other sites are
>smaller
>> sub sets of the operation db.  Additionally, for customer service we need
>to
>> keep records of products after they are discontinued.

>> Because of data integrity issues, I don't want all users in all
>departments
>> to have access to main file that will contain all products. Rather I'm
>> thinking I should create child files for each dept. Each one of these
>would
>> have a rel. to the master. Then they can add their own fields, create
>> reports, scripts etc. But never change or delete anything from the
master.

>> Is this even a feasible way to go about this?

>> If so, I'm not sure how to setup the relationships, so that each child
>sees
>> only records that should be in their "universe".

>> TIA

>> Lew



Tue, 08 Feb 2005 20:20:50 GMT
 Linking files?
Hi Lew,

it sounds as is you are simply (ha ha) wanting to tag central records to be
available to any combination of three departments.
I assume tat there is a unique product serial ID.

why not create an Available_to_Dept. field in the main file and use it as a
multiline key; using for example "A" for dept. A, "B" for dept B...

product ID 1, ex field value:
A
B
C

product ID 2, ex field value:
C
D

in each deptartment db, creat a Dept_code field as text autoenter, A for dept
A... create rels from each dept db Dept_code field to the central db
Available_to_Dept. field key.

so dept a would only see products tagged as available to their dept. Product 1
available to depts, ABC, product 2 to only C and D

Variations on the above could utilise concatenations of dept code and product
ID... or

THe Multiline key could just as esily be a calc that compiles from a set of
status fields:
discontinued ; key = customer service code
current ; key = sales and maketing code & carriage return & web code

too simple?

regards

Chris

Chris Brown
Neurosurgery
University of Adelaide

Quote:

> I need some suggestions.  Here's the problem

> We are trying to centralize our Products / Inventory database. It's
> currently in three separate departments. It starts in Marketing where they
> work only with current (still can order) and future products. They are
> currently using excel. Second, Is operations in our business software
> (MAS90) they only deal with in stock or backordered products. Third, we
> maintain five websites, using filemaker as the front end. One of these sites
> will have the same products as the marketing db. The other sites are smaller
> sub sets of the operation db.  Additionally, for customer service we need to
> keep records of products after they are discontinued.

> Because of data integrity issues, I don't want all users in all departments
> to have access to main file that will contain all products. Rather I'm
> thinking I should create child files for each dept. Each one of these would
> have a rel. to the master. Then they can add their own fields, create
> reports, scripts etc. But never change or delete anything from the master.

> Is this even a feasible way to go about this?

> If so, I'm not sure how to setup the relationships, so that each child sees
> only records that should be in their "universe".

> TIA

> Lew



Fri, 11 Feb 2005 08:21:51 GMT
 Linking files?

Quote:

> it sounds as is you are simply (ha ha) wanting to tag central records to
>be
> available to any combination of three departments.
> I assume tat there is a unique product serial ID.

Exactly ! Chris

Quote:
> why not create an Available_to_Dept. field in the main file and use it as
>a
> multiline key; using for example "A" for dept. A, "B" for dept B...
>The multiline key is a total new one on me. I 've done some research &
>playing. I think I'm getting it but I've got some questions.

1. I want these to be seprate files, it looks like the multiline key has to
be a concatenation of dept code and product Id, for the Dept files to get
the related fields.

If not I'll go back and try to find what missed.

If this is correct, is a script requried to calc this feild?

2. If I'm understanding this correctly, I'll need a record in the Dept file,
with the Product_ID and Dept_code , for every record that's in the central
file. Correct?

Thanks again

Lew
BTW my home wine collection project is going great!....



Sat, 12 Feb 2005 20:15:52 GMT
 Linking files?


Quote:

>> it sounds as is you are simply (ha ha) wanting to tag central records to
>> be
>> available to any combination of three departments.
>> I assume tat there is a unique product serial ID.

> Exactly ! Chris

>> why not create an Available_to_Dept. field in the main file and use it as
>> a
>> multiline key; using for example "A" for dept. A, "B" for dept B...
>> The multiline key is a total new one on me. I 've done some research &
>> playing. I think I'm getting it but I've got some questions.

> 1. I want these to be seprate files, it looks like the multiline key has to
> be a concatenation of dept code and product Id, for the Dept files to get
> the related fields.

> If not I'll go back and try to find what missed.

> If this is correct, is a script requried to calc this feild?

No Script, you need a calc field [stored] Product_ID & "?" & Dept_Code .
Quote:
> 2. If I'm understanding this correctly, I'll need a record in the Dept file,
> with the Product_ID and Dept_code , for every record that's in the central
> file. Correct?

Yes, use the calc field above.

Quote:
> Thanks again

> Lew
> BTW my home wine collection project is going great!....

--
Michael Stout

http://www.fmpdev.com/


Sat, 12 Feb 2005 23:09:12 GMT
 Linking files?


Quote:

> No Script, you need a calc field [stored] Product_ID & "?" & Dept_Code .

Sorry, I'm still missing something. When I use this for the calc field I
get:

Product_ID
Dept_Code
Dept_Code

With that in the Key Field I can't get the rel to work. The only way I can
get it to work. Is to have key field look like this:

Product_ID Dept_Code
Product_ID Dept_Code
Product_ID Dept_Code

Thoughts on what I'm missing?

Thanks again

Lew



Sun, 13 Feb 2005 05:22:35 GMT
 Linking files?
Lew,

the original suggestion was to use just the dept code. Products in the
Product file would be listed in the Dept file by  arel from each Dept db to
the central Product db, by a rel dept_code to key_ml. I assume you have tried
this to get the idea.

To then get a little more complicated: where it is going wrong intially;
think of what you have at the moment as an addition equation (A+B)
what you need is intermediate calcs (or  amore complicated text calc) to
achieve. The initial key_ml is more accurately a dept_code_ml
ID+A
ID+B
ID+C

So the calc logic will be:
ID + the first line of the dept_code_ml
ID + second line of the dept_code_ml ...

this requires syntax using middle and position text  functions, that use the
character position of each carriage return, and extract the text between
subsequent carriage returns (i.e. line). A bit of a head scratch at first
encounter, but you get used to it... if this is what you want we can detail
the calc syntax

I'm still digesting your earlier post...

chris

Quote:




> > No Script, you need a calc field [stored] Product_ID & "?" & Dept_Code .

> Sorry, I'm still missing something. When I use this for the calc field I
> get:

> Product_ID
> Dept_Code
> Dept_Code

> With that in the Key Field I can't get the rel to work. The only way I can
> get it to work. Is to have key field look like this:

> Product_ID Dept_Code
> Product_ID Dept_Code
> Product_ID Dept_Code

> Thoughts on what I'm missing?

> Thanks again

> Lew

--
regards

Chris

Chris Brown
Dept. Neurosurgery
University of Adelaide



Sun, 13 Feb 2005 08:01:35 GMT
 Linking files?
Hi Lew,

I'm unclear about which files you want to be separate files.

one central Product file with all product records, with Multiline field
Dept_code_ml
an individual Dept file, for each dept, each having a Dept_code field (Dept.A;
Dept_code field value ="a", ...)
a rel from each dept to the central Product file, Dept_code::Dept_code_ml
this is essentially a constant relationship, and will show all records in the
Product file, in a portal in the Dept file that have the same dept code value
in the  central multiline code field.

The Dept file therefore could at this stage only have one record, to show the
SUBSET of ALL records in the central Products file that are tagged with the
particular dept code.

What you then do with new creating records within the Department  file, is
where concatenated keys may be required. If for example, a depatrtment sold
items, and was invoicing...

Can you give a specific example for a single dept?

2. If I'm understanding this correctly, I'll need a record in the Dept file,
with the Product_ID and Dept_code , for every record that's in the central
file. Correct?
<<

no, this would be data redundancy.

regards

Chris

Quote:


> > it sounds as is you are simply (ha ha) wanting to tag central records to
> >be
> > available to any combination of three departments.
> > I assume tat there is a unique product serial ID.

> Exactly ! Chris

> > why not create an Available_to_Dept. field in the main file and use it as
> >a
> > multiline key; using for example "A" for dept. A, "B" for dept B...
> >The multiline key is a total new one on me. I 've done some research &
> >playing. I think I'm getting it but I've got some questions.

> 1. I want these to be seprate files, it looks like the multiline key has to
> be a concatenation of dept code and product Id, for the Dept files to get
> the related fields.

> If not I'll go back and try to find what missed.

> If this is correct, is a script requried to calc this feild?

> 2. If I'm understanding this correctly, I'll need a record in the Dept file,
> with the Product_ID and Dept_code , for every record that's in the central
> file. Correct?

> Thanks again

> Lew
> BTW my home wine collection project is going great!....

--
regards

Chris

Chris Brown
Dept. Neurosurgery
University of Adelaide



Sun, 13 Feb 2005 08:13:45 GMT
 Linking files?

Quote:

>the original suggestion was to use just the dept code. Products in the
>Product file would be listed in the Dept file by  arel from each Dept db to
>the central Product db, by a rel dept_code to key_ml. I assume you have
tried
>this to get the idea.

Yea, Thought I did. I just couldn't make fly. I'll go back and try this
again.

Quote:

>To then get a little more complicated: where it is going wrong intially;
>think of what you have at the moment as an addition equation (A+B)
>what you need is intermediate calcs (or  amore complicated text calc) to
>achieve. The initial key_ml is more accurately a dept_code_ml
>ID+A
>ID+B
>ID+C

>So the calc logic will be:
>ID + the first line of the dept_code_ml
>ID + second line of the dept_code_ml ...

>this requires syntax using middle and position text  functions, that use
the
>character position of each carriage return, and extract the text between
>subsequent carriage returns (i.e. line). A bit of a head scratch at first
>encounter, but you get used to it... if this is what you want we can detail
>the calc syntax

Actually this makes perfect sense to me. I'll see how far I can get with the
syntax.

- Show quoted text -

Quote:

>I'm still digesting your earlier post...

>chris





>> > No Script, you need a calc field [stored] Product_ID & "?" & Dept_Code
.

>> Sorry, I'm still missing something. When I use this for the calc field I
>> get:

>> Product_ID
>> Dept_Code
>> Dept_Code

>> With that in the Key Field I can't get the rel to work. The only way I
can
>> get it to work. Is to have key field look like this:

>> Product_ID Dept_Code
>> Product_ID Dept_Code
>> Product_ID Dept_Code

>> Thoughts on what I'm missing?

>> Thanks again

>> Lew

>--
>regards

>Chris

>Chris Brown
>Dept. Neurosurgery
>University of Adelaide



Sun, 13 Feb 2005 08:58:14 GMT
 Linking files?

Quote:

>one central Product file with all product records, with Multiline field
>Dept_code_ml
>an individual Dept file, for each dept, each having a Dept_code field
(Dept.A;
>Dept_code field value ="a", ...)
>a rel from each dept to the central Product file, Dept_code::Dept_code_ml
>this is essentially a constant relationship, and will show all records in
the
>Product file, in a portal in the Dept file that have the same dept code
value
>in the  central multiline code field.

OK I think I got it working now.  But I don't think this will help me with
what I trying to do.

Quote:
>The Dept file therefore could at this stage only have one record, to show
the
>SUBSET of ALL records in the central Products file that are tagged with the
>particular dept code.

>What you then do with new creating records within the Department  file, is
>where concatenated keys may be required. If for example, a depatrtment sold
>items, and was invoicing...

>Can you give a specific example for a single dept?

I think I've done a poor job of stating my objective. This maybe a better
way of saying what I want.
Each dept. would have their own file so that they can create  fields,
scripts & reports...Then it would validate against the central file for the
correct Product_ID, common fields, and whether or not they had all, and only
the products they should have.

Maybe why I want this would help. This is not a finished solution.  I'm just
now getting people in each dept to start using FMP so I don't want then in
the central db. I'd like them feel free to make mistakes and know it's not
going effect anyone else.  Each Dept will have fields that will be unique to
their needs. Yet, I need a central db to assure standardization of Prod_ID
and a few other common fields.

As always thanks in advance

Lew



Sun, 13 Feb 2005 10:13:14 GMT
 Linking files?
Hi Lew,

Ok, all sounds normal.
Central db Products.
peripheral dept. Front end db with unique dept code
rel to products based on dept code, so that only products tagged with that dept
code are visible to that dept.

the dept wants to 'grab' a couple of products and do something with them. For
example, sell 5 of product A, and 7 of product B,  to Company A, The simplest
scenario:
new record in Dept_A: Sales_db (with the rel established and the Dept_code auto
entered. This record has a unique ID (an invoice number, a job no...)
create  a field Product ID in Dept_A: Sales_db and add to the layout

create a portal listing all the (code available) products; add the portal to
the layout using the rel, add related Product field to the portal (product,
product descripion, product ID, cost or other cenbtralised product data)
now you can scroll the list for the product you require.
You could then type in the required product ID in the new record Product ID
field, do the same for the second product on a new record, entering the qty and
sold to who details in relevant fields. So you now have a list of sold items
for Dept_A, complete with details re cost, who to etc. This is the most simple
method, more for illustration.

The point is the dept code gives you filtered access to the central product db
using a portal you can find and then grab the product ID
you can then use the product ID i a second relationship to show other data for
just that product in the central Product db, without data
redundancy/duplication

The next level is to refine/restructure how you grab and store the ID's. A
scripted button on the portal row  that grabs the ID and sets the local Dept
ProductID field would be easier than typing it. In the main dept db, each
record would be better as a unique invoice or job number, with  a portal to  a
second departmental db based on this invoice number...  that allows the sold to
detalis to only be entered once etc. But that may be getting ahead of where you
are at at the moment. But briefly

Central product db
Dept. Invoice/job db A
Dept. Invoice/job details db B

rel dbA::dbB using invoice number
fields in A: invoice number, sold to....
fields in B: invoice number, qty, cost., modification required...
portal using this rel in A: add field product ID
second portal (the one discuss earlier, listing the products), with a button
and script that grabs the portal row product ID, and sets the product ID field
in B (along with cost...), thereby creating  asingle record in B for each
invoice/job, and a single record in B for each product for that invoice/job (ie
multiple records in B for each record in A)

this keeps all the central data central and uncorruptable, but pulls down the
product ID and stores relevant IDs locally for each job, whatever local data
required can then be added to the local files

regards

Chris

Quote:


> >one central Product file with all product records, with Multiline field
> >Dept_code_ml
> >an individual Dept file, for each dept, each having a Dept_code field
> (Dept.A;
> >Dept_code field value ="a", ...)
> >a rel from each dept to the central Product file, Dept_code::Dept_code_ml
> >this is essentially a constant relationship, and will show all records in
> the
> >Product file, in a portal in the Dept file that have the same dept code
> value
> >in the  central multiline code field.

> OK I think I got it working now.  But I don't think this will help me with
> what I trying to do.

> >The Dept file therefore could at this stage only have one record, to show
> the
> >SUBSET of ALL records in the central Products file that are tagged with the
> >particular dept code.

> >What you then do with new creating records within the Department  file, is
> >where concatenated keys may be required. If for example, a depatrtment sold
> >items, and was invoicing...

> >Can you give a specific example for a single dept?

> I think I've done a poor job of stating my objective. This maybe a better
> way of saying what I want.
> Each dept. would have their own file so that they can create  fields,
> scripts & reports...Then it would validate against the central file for the
> correct Product_ID, common fields, and whether or not they had all, and only
> the products they should have.

> Maybe why I want this would help. This is not a finished solution.  I'm just
> now getting people in each dept to start using FMP so I don't want then in
> the central db. I'd like them feel free to make mistakes and know it's not
> going effect anyone else.  Each Dept will have fields that will be unique to
> their needs. Yet, I need a central db to assure standardization of Prod_ID
> and a few other common fields.

> As always thanks in advance

> Lew

--
regards

Chris

Chris Brown
Dept. Neurosurgery
University of Adelaide



Sun, 13 Feb 2005 11:11:23 GMT
 Linking files?
Chris Thanks!! This is the exact model I had asked for. I'll try to work
through details see how far I get. If I have any question s I'll start a new
thread.

Thanks Again

Lew


Quote:
> Hi Lew,

> Ok, all sounds normal.
> Central db Products.
> peripheral dept. Front end db with unique dept code
> rel to products based on dept code, so that only products tagged with that
dept
> code are visible to that dept.

> the dept wants to 'grab' a couple of products and do something with them.
For
> example, sell 5 of product A, and 7 of product B,  to Company A, The
simplest
> scenario:
> new record in Dept_A: Sales_db (with the rel established and the Dept_code
auto
> entered. This record has a unique ID (an invoice number, a job no...)
> create  a field Product ID in Dept_A: Sales_db and add to the layout

> create a portal listing all the (code available) products; add the portal
to
> the layout using the rel, add related Product field to the portal
(product,
> product descripion, product ID, cost or other cenbtralised product data)
> now you can scroll the list for the product you require.
> You could then type in the required product ID in the new record Product
ID
> field, do the same for the second product on a new record, entering the
qty and
> sold to who details in relevant fields. So you now have a list of sold
items
> for Dept_A, complete with details re cost, who to etc. This is the most
simple
> method, more for illustration.

> The point is the dept code gives you filtered access to the central
product db
> using a portal you can find and then grab the product ID
> you can then use the product ID i a second relationship to show other data
for
> just that product in the central Product db, without data
> redundancy/duplication

> The next level is to refine/restructure how you grab and store the ID's. A
> scripted button on the portal row  that grabs the ID and sets the local
Dept
> ProductID field would be easier than typing it. In the main dept db, each
> record would be better as a unique invoice or job number, with  a portal
to  a
> second departmental db based on this invoice number...  that allows the
sold to
> detalis to only be entered once etc. But that may be getting ahead of
where you
> are at at the moment. But briefly

> Central product db
> Dept. Invoice/job db A
> Dept. Invoice/job details db B

> rel dbA::dbB using invoice number
> fields in A: invoice number, sold to....
> fields in B: invoice number, qty, cost., modification required...
> portal using this rel in A: add field product ID
> second portal (the one discuss earlier, listing the products), with a
button
> and script that grabs the portal row product ID, and sets the product ID
field
> in B (along with cost...), thereby creating  asingle record in B for each
> invoice/job, and a single record in B for each product for that
invoice/job (ie
> multiple records in B for each record in A)

> this keeps all the central data central and uncorruptable, but pulls down
the
> product ID and stores relevant IDs locally for each job, whatever local
data
> required can then be added to the local files

> regards

> Chris





Quote:
> > >one central Product file with all product records, with Multiline field
> > >Dept_code_ml
> > >an individual Dept file, for each dept, each having a Dept_code field
> > (Dept.A;
> > >Dept_code field value ="a", ...)
> > >a rel from each dept to the central Product file,

Dept_code::Dept_code_ml

- Show quoted text -

Quote:
> > >this is essentially a constant relationship, and will show all records
in
> > the
> > >Product file, in a portal in the Dept file that have the same dept code
> > value
> > >in the  central multiline code field.

> > OK I think I got it working now.  But I don't think this will help me
with
> > what I trying to do.

> > >The Dept file therefore could at this stage only have one record, to
show
> > the
> > >SUBSET of ALL records in the central Products file that are tagged with
the
> > >particular dept code.

> > >What you then do with new creating records within the Department  file,
is
> > >where concatenated keys may be required. If for example, a depatrtment
sold
> > >items, and was invoicing...

> > >Can you give a specific example for a single dept?

> > I think I've done a poor job of stating my objective. This maybe a
better
> > way of saying what I want.
> > Each dept. would have their own file so that they can create  fields,
> > scripts & reports...Then it would validate against the central file for
the
> > correct Product_ID, common fields, and whether or not they had all, and
only
> > the products they should have.

> > Maybe why I want this would help. This is not a finished solution.  I'm
just
> > now getting people in each dept to start using FMP so I don't want then
in
> > the central db. I'd like them feel free to make mistakes and know it's
not
> > going effect anyone else.  Each Dept will have fields that will be
unique to
> > their needs. Yet, I need a central db to assure standardization of
Prod_ID
> > and a few other common fields.

> > As always thanks in advance

> > Lew

> --
> regards

> Chris

> Chris Brown
> Dept. Neurosurgery
> University of Adelaide



Mon, 14 Feb 2005 05:14:34 GMT
 
 [ 13 post ] 

 Relevant Pages 

1. Problem using Data Link file from ATL COM DLL

2. HOW DO I INSERT USING OPENQUERY INTO A ACCESS LINKED FILE

3. Problem: Cross Linked File

4. Linker Server - Can't link file on network

5. Link files for Paradox 9

6. HOW DO I INSERT USING OPENQUERY INTO A ACCESS LINKED FILE

7. Cross Linked Files

8. data link file udl vs mdl and visual basic

9. creating data link file

10. linking files

11. Creating Data Link file

12. Can DataEnvironment using data link file?


 
Powered by phpBB® Forum Software