SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 41
  1. #1
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)

    Continued normalization questions

    Moving this to its own thread.

    Carrying on a discussion from Problem grouping areas in my database

    Which was me extending a discussion of r937s called A question about normalization

    Quote Originally Posted by Cups
    Isn't the lesson from that post this. That as long as each row only has one "attribute" (country) then its probably ok to leave it all in one table?

    id - country - city
    1 - France - Paris
    (PK - "attribute" - value)
    At which point I thought I had grasped something ....

    Only to lose that elated feeling when he posted:

    Quote Originally Posted by r937
    yes, that's it, except obviously a row can have many attributes, not just one

    the idea of functional dependency is that if i give you a value for the primary key, can you unambiguously tell me the value of any column in that row
    So trying to discover what FD was I found this on wikipedia
    Quote Originally Posted by wikipedia Functional Dependency
    Given a relation R, a set of attributes X in R is said to functionally determine another attribute Y, also in R, (written X → Y) if and only if each X value is associated with precisely one Y value.
    Quote Originally Posted by Cups
    So what that means is that the table were to be extended to include trading-blocs, like CIS or Americas:

    id - bloc - country - city
    1 - EU - France - Paris
    2 - CIS - Russia - Moscow
    (PK - "attribute" - "attribute" - value)

    Then this would still lead to more efficient queries?

    (I snipped out an example about rainfall because it didn't clarify anything in my mind.)
    Rudy replied "wha?"

    So, now I am totally confused and asking:
    Well traditionally I, and many PHPers would normalize that table into 3 tables almost as a knee jerk reaction.

    Blocs, countries and cities.

    But I can see that having a single table could lead to simpler sql ( although it might mean the programming logic in PHP could have to do more work in certain situations).

    What is the general rule of thumb that tells you when you should split the tables up, or what I and others would perhaps mistakenly call "normalizing" them.

    Is Functional Dependency a good thing, bad thing, or just a means of describing a state? (no pun intented)

    Although this is an sql subject, I think that grasping this could have side effects on my PHP thinking too.
    *phew*

  2. #2
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    Well traditionally I, and many PHPers would normalize that table into 3 tables almost as a knee jerk reaction.

    Blocs, countries and cities.

    But I can see that having a single table could lead to simpler sql ( although it might mean the programming logic in PHP could have to do more work in certain situations).

    What is the general rule of thumb that tells you when you should split the tables up, or what I and others would perhaps mistakenly call "normalizing" them.
    Consider going hierarchical
    Columsn in a region table for:
    region
    region_type
    parent_region

    Code:
    Values in the table might include:
    region       region_type    parent_region
    --------    -------------   ---------------
    EU          BLOC            null
    France      Country         EU
    Paris       City            France
    Marseilles  City            France
    England     Country         EU
    England     Country         NATO
    London      City            England
    Berkshire   County          England
    It's a bit awkward only allowing a single parent for any entry, but it's a more generic rationalisation of your basic geographic structure
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  3. #3
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Mark, you may well be correct, hierarchical is something I read about from time to time - but I have never used it - partly because my sql thinking is so ingrained and perhaps entrenched ( I still go, crikey it works!).

    What are the deciding factors that make you decide to use a hierarchical model ( I know enough to know there are a few systems )

  4. #4
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    Mark, you may well be correct, hierarchical is something I read about from time to time - but I have never used it - partly because my sql thinking is so ingrained and perhaps entrenched ( I still go, crikey it works!).
    Probably more data structures are inherently hierarchical than most people realise. If the basic data at each level within a hiererchy has the same attributes, then it can probably be depicted as a hierarchy, evn though the "real world" names vary depending on the level within the hierarchy.

    Codd's rules dictate that we normalise, which leads to a mindset that defines each 'level' in a different table... possibly resulting in less efficient data structures; but it's only in recent years that most relational databases have provided functionality for handling hierarchies of data (relationships between rows within a table) rather than the more traditional relationships between tables.

    I guess I come from a manufacturing background, where hierarchies are much more ingrained in the mindset, rather than from a "relational" background.

    Quote Originally Posted by Cups View Post
    What are the deciding factors that make you decide to use a hierarchical model ( I know enough to know there are a few systems )
    Certain data structures do lend themselves naturally to a hierarchical data structure... Bill of Materials on an assembly line being an obvious example; process manufacturing is another less obvious example because it's typically a reverse Bill of Materials, where (for example) refining crude oil can provide a number of different grades of refines oil... but it's still a hierarchy. Organisational structures are another very obvious example: I manage a number of staff, but am myself managed by a senior director who answers to the CEO.
    Geographic data is also inherently hierarchical: the world comprises continents, each of which consists one or more countries, with regions, cities, and streets, down to individual houses. But the key data attributes that can be used to define each level within the structure are basically the same.

    EDIT: Hierarchical does become more complex when you have multiple relationships both up and down the tree. The UK is part of the EU (a trade block), a part of NATO (a military block), and of Europe (a geographical block), so potentially it has multiple parents as well as multiple children at varying levels: UK comprises Great Britain and Northern Ireland; Great Britain comprises England, Scotland and Wales; etc.
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  5. #5
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    hierarchies are nothing more than a chain of one-to-many relationships

    and a one-to-many relationship is what you have whenever you create a foreign key

    do you want to talk about functional dependencies any more, or switch the conversation to foreign keys?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  6. #6
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    @mark - thanks, I think I get the picture with that comment.

    The UK is part of the EU (a trade block), a part of NATO (a military block), and of Europe (a geographical block), so potentially it has multiple parents as well as multiple children at varying levels: UK comprises Great Britain and Northern Ireland; Great Britain comprises England, Scotland and Wales; etc.
    However I mistakenly thought maybe hierarchical models were somehow leading out from the question of FD.

    r937 No no please continue - I keep re-reading the post and thought I grasped what you were saying - but then it fades away like mist before my eyes.

    In certain situations is a single table classed as N3, and why is it preferable - is it more efficient or is it just easier to design and handle.

    What are the pressures that cause you to break the tables up, or conversely what are the signs that 3 tables would be better consolidated into 1?

    I have a hunch that understanding this could have a dramatic effect on refactoring code.

  7. #7
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    N3?

    pressures?

    refactoring?

    thou speakest a tongue with which i hast no familiarity



    maybe i should walk you through an example of normalization? care to suggest one?

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  8. #8
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Right, how about we stick with the example in the last thread.

    lets say we have trading blocs, countries and cities.

    Most phpers here would make 3 tables.

    Thats partly because we have applications that reflect those relations very nicely.

    Step 1 pick a block
    Step 2 pick a country from that block
    Step 3 pick a city from a country

    The 3 table set up works really nicely, "select id, country from countries" gives you urls like
    <a href=cities.php?country=1>France</a>
    <a href=cities.php?country=2>Spain</a>
    <a href=cities.php?country=3>Canada</a>
    etc.

    If I understand your point a single table should not be ruled out.

    id - bloc - country - city
    ==================
    1 - EU - France - Paris

    At what point is that a better solution?

  9. #9
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by r937 View Post
    N3?
    3rd Normal Form (I think)


    Quote Originally Posted by r937 View Post
    refactoring?
    Coder term: anything from passing an additional parameter to a function to a complete rewrite.

    I think there's also a degree of mindset clash between the multiple-table approach of a relational data structure, and OOP, where coders try to create a generic class for any database table that can then be extended.
    Database design will typically break a composite entity into a set of relational tables: OOP coder will try to reduce their code logic to a single core object, and handle every variant through extensions.
    There's also the tendency to create a class per database table rather than per composite entity.
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  10. #10
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    @Mark I think you are correct, but I also think its even deeper ingrained than that - for the reasons I explained about us reflecting our users behaviour of drilling down through tables.

    Even to the stage that we force our users to follow what we perceive to be "steps" we have (perhaps wrongly) modeled into our databases from the get go.

  11. #11
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    sorry, OOP references like "object" and "class" are totally lost on me

    regarding your example -- drilling down through a hierarchy, and reflecting available choices at each step in the dropdown options available in the next step, well, that has very little to do with normalization

    three tables, one table, do whatever you feel is better from a programming point of view

    both structures are normalized

    both structures can be optimized for query performance, although i daresay that if you never access the hierarchy except in those three discrete steps, then the three-table approach makes a bit more sense

    care to pick a different example?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  12. #12
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    r937 simplistically, can I start with this as a schema, then add more as we go maybe?

    tables

    blocs
    ====
    id
    bloc

    countries
    =======
    id
    country

    cities
    ====
    id
    city

    Off Topic:

    Sorry cross post .. let me think ...

  13. #13
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    No, I got that wrong.

    tables
    =====

    blocs
    ====
    id
    bloc

    countries
    =======
    id
    bloc_ref
    country

    cities
    ====
    id
    country_ref
    city

    I had previously said:
    The 3 table set up works really nicely, "select id, country from countries" gives you urls like:
    <a href=cities.php?country=1>France</a>
    <a href=cities.php?country=2>Spain</a>
    <a href=cities.php?country=3>Canada</a>

    The total 3 corresponding "pages" containing required sql statements would be like this


    page 1 pick a bloc:
    "select id, bloc from blocs"

    resulting in urls like this on page 1:

    <a href=countries.php?bloc=1>EU</a>
    <a href=countries.php?bloc=2>CIS</a>

    Page 2 has this:

    "select id, country from countries where bloc_ref=1"

    <a href=cities.php?country=1>France</a>
    <a href=cities.php?country=2>Spain</a>
    <a href=cities.php?country=3>Canada</a>

    Page 3 has this:

    "select id, city from cities where country_ref = 1"

    To finally show a list of cities for each country.

    Now if they were all in a single table those selects would be dependent upon text comparison rather that abstracted numbers.

    id - bloc - country - city
    ==================
    1 - EU - France - Paris

    "select country from cities where bloc = 'EU'";

    "select city from cities where country = 'France'";

    and the urls would look like this:

    <a href=cities.php?bloc=EU>
    <a href=cities.php?bloc=EU>

    <a href=cities.php?country=France>
    <a href=cities.php?country=Spain>

    Just by doing that I can see some very important differences.

    1 A BIT BAD for security purposes, we are no longer checking just for an integer before doing the query based on the user input- we have to check with a regex

    2 GOOD or BAD? the database has to do a look up based on text comparison rather than compare an int - I thought databases preferred numbers ?

    3 GOOD the url has semantic meaning (user friendly in many, many ways)

    4 GOOD there is only one table

    5 JOLLY GOOD url rewrite rules don't need to be decipher the numbers

    Because a lot of us have got .htaccess files that do things like this:

    if the url is /countries/France then get the content of the page /countries.php?decipher_this_thing=France

    Because countries.php now has to look up France and find out which flipping number it is before I can get the cities.

    Which is a darn site harder than simply doing:

    "if the url is /countries/France then get the content of page /countries.php?country=France"

    Sorry r937, I just had a stream of consciousness that seems to solve a load of repetitive tasks I have to do, failure points that perhaps don't need to be there.

    So what would spoil a single table representation, because so far, I am sold.

  14. #14
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Even if i then had transit systems to add to the mix.

    id - bloc - country - city - transit
    ==========================
    1 - EU - France - Paris - bus
    2 - EU - France - Paris - train
    3 - EU - France - Paris - metro
    4 - EU - France - Paris - taxi

    This single row schema still works.

    So the critera you stated was:

    the idea of functional dependency is that if i give you a value for the primary key, can you unambiguously tell me the value of any column in that row
    In which situation does that not apply then?

    Can you give me an example?

  15. #15
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    i'm really enjoying this thread, because so far, i haven't said anything

    let me make some comments

    1 A BIT BAD? no

    no regex is required (although checking for SQL injection is needed)

    if the string submitted does not match a bloc, you say "bloc not found"

    interestingly, this is the same error message if you don't find a number


    2 GOOD or BAD? either

    i bet you cannot detect a timing difference if you set up a proper volume test and clear the cache in between


    3 GOOD yep, good

    you are starting to warm up to the concept of a natural key


    4 GOOD hmmm

    just one table isn't always a good idea


    5 JOLLY GOOD yep

    another programming advantage


    did you want to bring the discussion back to FDs?
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  16. #16
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Code:
    id    region      parent_region
    ---   --------    ---------------
    1     EU          0
    2     CIS         0
    3     France      1
    4     Spain       1
    5     Italy       1
    6     Paris       3
    7     Marseilles  3
    8     Madrid      4
    9     Barcelona   4
    10    Rome        5
    11    Naples      5
    Query for page 1: Pick a block

    PHP Code:
    select id,
           
    region 
      from regions
     where parent_region 
    $parentID 

    Query for page 2: Pick a country

    PHP Code:
    select id,
           
    region 
      from regions
     where parent_region 
    $parentID 

    Query for page 3: Pick a city

    PHP Code:
    select id,
           
    region 
      from regions
     where parent_region 
    $parentID 

    Quote Originally Posted by Cups View Post
    1 A BIT BAD for security purposes, we are no longer checking just for an integer before doing the query based on the user input- we have to check with a regex
    It's still just an integer

    Quote Originally Posted by Cups View Post
    2 GOOD or BAD? the database has to do a look up based on text comparison rather than compare an int - I thought databases preferred numbers ?
    It's still just an integer

    Quote Originally Posted by Cups View Post
    3 GOOD the url has semantic meaning (user friendly in many, many ways)
    No semantic meaning

    Quote Originally Posted by Cups View Post
    4 GOOD there is only one table
    Only one table

    Quote Originally Posted by Cups View Post
    5 JOLLY GOOD url rewrite rules don't need to be decipher the numbers
    Numbers for id values

    6 GOOD Same query for every level of access. Only one class/script required to handle all levels

    7 GOOD Easy to add new levels in the future
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  17. #17
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    i don't understand the predeliction for numeric ids all over the place, guys

    you can just as easily do mark's hierarchy without them --
    Code:
    region     parent_region
    ------     ---------------
    EU         -
    CIS        -
    France     EU
    Spain      EU
    Italy      EU
    Paris      France
    Marseilles France
    Madrid     Spain
    Barcelona  Spain
    Rome       Italy
    Naples     Italy
    the queries for the "three steps" are remarkably similar, except they don't involve numbers



    mark, you should use NULL for your FKs at the top of the hierarchy

    if you've ever tried to implement this structure using actual FKs, you will have found that it is impossible to enter any row with 0 as the parent

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  18. #18
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by r937 View Post
    mark, you should use NULL for your FKs at the top of the hierarchy
    Yeah, I know.

    Quote Originally Posted by r937 View Post
    if you've ever tried to implement this structure using actual FKs, you will have found that it is impossible to enter any row with 0 as the parent
    I've not used hierarchical queries in mySql, but it's perfectly possible in Oracle (if you're only looking down the tree)... just entails START WITH parent_region=0... but I know that it causes problems looking up from a leaf to the root. My working examples all use NULL parent in the data tables, though I often use a NVL(parent_region,0) in hierarchical views.

    EDIT: Using non-numeric PKs could also have some benefit in a URL rewrite as well. Assuming that the full current->root tree is passed back from the database to the script, the URLs could be set as /EU/France/Paris with only the last atom of the URL needed for the next level of the query.
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  19. #19
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    the oracle syntax for START WITH doesn't get you around the logjam that the FK cannot refer to a zero PK

    in oracle, if you have an empty table, can you insert the first row with PK=0 and FK=0 referring to itself?

    i thought not
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  20. #20
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    integers are easier to frisk than strings
    Quote Originally Posted by r937
    1 A BIT BAD? no

    no regex is required (although checking for SQL injection is needed)
    Well, how'd you detect an sql inj attack?

    With an integer field its a snap with PHP, you tell PHP to turn the string into an integer, it returns 0 if the result is not a recognised integer.

    But with strings its only a matter of checking the incoming string contains the characters you allow.

    I suppose that with prepared statements in PDO and the like it makes sure the input is correctly filtered, but then we have to catch that mysql error and deal with it.

    That's just a PHP security coding habit to modify though.

    re: prefering text keys over numeric keys:
    Quote Originally Posted by r937
    2 GOOD or BAD? either

    i bet you cannot detect a timing difference if you set up a proper volume test and clear the cache in between
    I was hoping you would say that.

    You see that is a myth that needs debunking, and I have to admit I have been a protagonist of that myth, "databases prefer numbers".

    @r937, mark

    Its getting late over here - so I am going to re-read this from the start in the morning if you don't mind because I am afraid I am starting to lose the point of the thread just a tad.

    This has really got me thinking though, you see I have one eye on Semantic Web discussions too, and I am really quite pleasantly surprised with what I have discovered so far.

    I wonder if inserting and maintaining data carries as many benefits.

    Natural keys hmmm... going to have to look that one up now.

    So what, in easy to understand terms, are FDs?

  21. #21
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Cups View Post
    So what, in easy to understand terms, are FDs?
    FDs are relationships between column values

    but let's pick that up again tomorrow

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  22. #22
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  23. #23
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    This is an interesting conversation. This doesn't seem to work and you were referencing the ability to create foreign keys that actually reference the same table. How would you do that or can a functional dependency only be implied?

    Code:
    create table navigation (
    	name varchar(20) NOT NULL
    	,parent_name varchar(20) NULL
    	,primary key(name)
    	,INDEX(parent_name)
    	,FOREIGN KEY(parent_name) REFERENCES navigation(name)
    ) ENGINE=INNODB;

  24. #24
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    So in regards to what your saying with primary keys taking this schema for example would the last be more beneficial? There won't be any type of performance lose because in the last I'm using a string as a primary key?

    Code:
    CREATE TABLE users (
    	id int(10) UNSIGNED NOT NULL auto_increment
    	,name varchar(15) NOT NULL	
    	,primary key(id)
    	,unique key(name)
    )ENGINE=INNODB;
    Code:
    CREATE TABLE users (
    	,name varchar(15) NOT NULL	
    	,primary key(name)
    )ENGINE=INNODB;

  25. #25
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,273
    Mentioned
    60 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by oddz View Post
    This doesn't seem to work ...
    what error message did you get? it works fine in 4.1
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •