one.com - pludselig virker mine php-sider ikke

Øhhh...

Nu har one.com en 24/7/365 dages livesupport, som oftest på engelsk og til tider på Dansk.

PRøv den

Min database virker fint......

Post evt. SQL'en her så vi kan hvad der menes med fejlmeddelsen.

Yep

one.com har døgn-support. Det betyder, at der svares inden for 24 timer. Og jeg har allerede sendt mit grundlæggende spørgsmål til dem. Det har resulteret i et (hurtigt) svar; at tegnsættet er lavet om (fra Latin1 til utf8) i forbindelse med opdatering af databasen. Desuden at jeg kunne forsøge at ændre mine tabeller CHARACTER SET... dette er gjort, men jeg får desværre den samme fejlmeddelelse.

Den fulde fejlbesked (via IE) ser sådan ud:
"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-1' at line 1"

Det skal måske tilføjes, at jeg har anvendt en extension til Dreamweaver der hedder "PHakt" som genererer en del PHP af sig selv. Jeg har en grim formodning om at jeg skal ind og rode i noget dér.

Og hvis man vil se fejlmeddelelsen selv, så bare klik på "Forum" eller "Seneste nyt" på http://www.ryesgade60.dk.

Iøvrigt har jeg et andet domæne hos one.com hvor siderne er bygget op på præcis de samme præmisser - og de virker endnu - men dér er opdateringen ikke trådt i kraft endnu. Det betyder, at jeg foreløbig ikke har fået alle mine tabellers kollation lavet om... endnu.

Det var ikke fejlmeddelelsen jeg bedte om :) Hvordan ser det SQL query som er årsag til fejlmeddelelsen ud?

Ja, det beklager jeg.

Jeg ved fra en bekendt med bedre kendskab til php, at den kode Dreamweaver laver kan se syret ud (især når man begynder at stille krav til sine udtræk), men se med hér på et basic eksempel:

// begin Recordset
$query_rs_NaviTTL = "SELECT * FROM vPG_oTtl";
$rs_NaviTTL = $rg60v2->SelectLimit($query_rs_NaviTTL) or die($rg60v2->ErrorMsg());
$totalRows_rs_NaviTTL = $rs_NaviTTL->RecordCount();
// end Recordset

Denne blok får browseren til at gi' fejlmeddelelse. Hvis jeg fjerner den helt (og php kode i body) vises siden fint

Jeg har forsøgt at finde betegnelsen 'latin' i de includes som Dreamweaver/PHakt anvender, men uden held. Jeg ved ikke helt hvilken type statement jeg skal lede efter - hvis altså det skulle være det nye character set der giver problemer.

Jeg kan tilføje, at one.com er igang med større opdateringsprocess og ikke er nået til alle servere endnu. Derfor er jeg nysgerrig efter at vide, om  mccookie's phpMyAdmin har ændret karakter for nylig.
- Det helt oplagte er, at man pludselig ser svensk latin character sets over det hele. Meget besynderligt!

Og så har de i øvrigt opgivet at hjælpe yderligere... de tørrer foreløbig sagen af på softwareproducenter.

Well, well... nu skal jeg desværre forlade min computer indtil sent i aften, men jeg bliver ikke ked af mange gode bud når jeg vender tilbage :-)

Det kan næppe være "SELECT * FROM vPG_oTtl" der volder fejl, så der må ske et eller andet med query'et i SelectLimit()

I forhold til forummet:
Hvad står der i Linie 1 ?

Problemet er tydeligvis skabt af det querybuilder system som spørgeren benytter.
Vi kan ikke hjælpe uden at se koden til det, eller det præcise SQL output.

Og det har intet med one.com at gøre, det er din kode som er fucked up.

"de tørrer foreløbig sagen af på softwareproducenter."
-- hvilket er korrekt, det gør jeg også :p (dvs. dig, eller den person som har kodet det system du bruger).

Morgan_freeman>>>

Virker din phpmyadmin og kan du selecte derfra?

windscape >> det er meget muligt, at min kode er fucked up, men det er sket efter at one.com har opdateret deres MySQL fra 4.0.24 til MySQL 4.1.11.
Alle mine sider virkede igår og virker ikke idag. Om man så kan betegne det som fucked up kode vil jeg lade eksperter afgøre

Min phpMyAdmin fungerer fint - og Dreamweaver/PHAkt kan også godt finde databasen, bare ikke lave et brugbart output på en online webside.

Hvad SQL line 1 angår er jeg ikke helt sikker, men dette er toppen af mit dokument:
<?php
//Connection statement
require_once('../Connections/rg60v2.php');

  og ../Connections/rg60v2.php ser således ud (hold fast):

<?php
    # PHP ADODB document - made with PHAkt
    # FileName="Connection_php_adodb.htm"
    # Type="ADODB"
    # HTTP="true"
    # DBTYPE="mysql"
   
    $MM_rg60v2_HOSTNAME = "localhost";
    $MM_rg60v2_DATABASE = "mysql:ryesgade60_dk";
    $MM_rg60v2_DBTYPE  = preg_replace("/:.*$/", "", $MM_rg60v2_DATABASE);
    $MM_rg60v2_DATABASE = preg_replace("/^.*?:/", "", $MM_rg60v2_DATABASE);
    $MM_rg60v2_USERNAME = "ryesgade60_dk";
    $MM_rg60v2_PASSWORD = "ApQ5X55m";
    $MM_rg60v2_LOCALE = "Us";
    $MM_rg60v2_MSGLOCALE = "En";
    $MM_rg60v2_CTYPE = "P";
    $KT_locale = $MM_rg60v2_MSGLOCALE;
    $KT_dlocale = $MM_rg60v2_LOCALE;
    $KT_serverFormat = "%Y-%m-%d %H:%M:%S";
    $QUB_Caching = "false";
   
    switch (strtoupper ($MM_rg60v2_LOCALE)) {
        case 'EN':
                $KT_localFormat = "%d-%m-%Y %H:%M:%S";
        break;
        case 'EUS':
                $KT_localFormat = "%m-%d-%Y %H:%M:%S";
        break;
        case 'FR':
                $KT_localFormat = "%d-%m-%Y %H:%M:%S";
        break;
        case 'RO':
                $KT_localFormat = "%d-%m-%Y %H:%M:%S";
        break;
        case 'IT':
                $KT_localFormat = "%d-%m-%Y %H:%M:%S";
        break;
        case 'GE':
                $KT_localFormat = "%d.%m.%Y %H:%M:%S";
        break;
        case 'US':
                $KT_localFormat = "%Y-%m-%d %H:%M:%S";
        break;
        default :
                $KT_localFormat = "none";           
    }


   
    if (!defined('CONN_DIR')) define('CONN_DIR',dirname(__FILE__));
    require_once(CONN_DIR."/../adodb/adodb.inc.php");
    ADOLoadCode($MM_rg60v2_DBTYPE);
    $rg60v2=&ADONewConnection($MM_rg60v2_DBTYPE);

    if($MM_rg60v2_DBTYPE == "access" || $MM_rg60v2_DBTYPE == "odbc"){
        if($MM_rg60v2_CTYPE == "P"){
            $rg60v2->PConnect($MM_rg60v2_DATABASE, $MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD,
            $MM_rg60v2_LOCALE);
        } else $rg60v2->Connect($MM_rg60v2_DATABASE, $MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD,
            $MM_rg60v2_LOCALE);
    } else if (($MM_rg60v2_DBTYPE == "ibase") or ($MM_rg60v2_DBTYPE == "firebird")) {
        if($MM_rg60v2_CTYPE == "P"){
            $rg60v2->PConnect($MM_rg60v2_HOSTNAME.":".$MM_rg60v2_DATABASE,$MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD);
        } else $rg60v2->Connect($MM_rg60v2_HOSTNAME.":".$MM_rg60v2_DATABASE,$MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD);
    }else {
        if($MM_rg60v2_CTYPE == "P"){
            $rg60v2->PConnect($MM_rg60v2_HOSTNAME,$MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD,
              $MM_rg60v2_DATABASE,$MM_rg60v2_LOCALE);
        } else $rg60v2->Connect($MM_rg60v2_HOSTNAME,$MM_rg60v2_USERNAME,$MM_rg60v2_PASSWORD,
              $MM_rg60v2_DATABASE,$MM_rg60v2_LOCALE);
  }

    if (!function_exists("updateMagicQuotes")) {
        function updateMagicQuotes($HTTP_VARS){
            if (is_array($HTTP_VARS)) {
                foreach ($HTTP_VARS as $name=>$value) {
                    if (!is_array($value)) {
                        $HTTP_VARS[$name] = addslashes($value);
                    } else {
                        foreach ($value as $name1=>$value1) {
                            if (!is_array($value1)) {
                                $HTTP_VARS[$name1][$value1] = addslashes($value1);
                            }
                        }
                       
                    }
                    global $$name;
                    $$name = &$HTTP_VARS[$name];
                }
            }
            return $HTTP_VARS;
        }
       
        if (!get_magic_quotes_gpc()) {
            $HTTP_GET_VARS = updateMagicQuotes($HTTP_GET_VARS);
            $HTTP_POST_VARS = updateMagicQuotes($HTTP_POST_VARS);
            $HTTP_COOKIE_VARS = updateMagicQuotes($HTTP_COOKIE_VARS);
        }
    }
    if (!isset($HTTP_SERVER_VARS['REQUEST_URI'])) {
        $HTTP_SERVER_VARS['REQUEST_URI'] = $HTTP_SERVER_VARS['PHP_SELF'];
    }
?>

OK DET VAR MÅSKE DET DUMMESTE JEG LÆNGE HAR SET.... ovennævnte koder burde naturligvis have været erstattet med uægte koder. Der må laves ting om

En mulig årsag, som kun er et gæt fra min side, er at one.com langt om længe har slået registerglobals fra. Dvs. har man brugt at    side.php?id=7913    bliver til en $id i koden helt automatisk, vil man nu få en tom streng, på de steder hvor $id indgår, og dermed vil man få "underlige" sql-fejl.

Prøv:
1)  Lav en .php fil kun med dette indhold:  <?php  phpinfo(); ?> 
    og giv os et link, eller kig selv efter registerglobals
2)  Check kontrolpanelet, om det er muligt for dig selv at slå registerglobals til eller fra. (Det kan evt. hedde noget andet)

Disclaimer: jeg kender absolut intet til (b-)one.com
Disclaimer2: Selv om det lykkes dig at slå registerglobals til og få din kode til at køre, er det grisset kode.

Erikjacobsen>>>

Som b(one).com kunde kan du selv vælge om du vil slå register global on or off. Vi naturligvis enige om at det bør den være sat til off.

Morgan_freeman>>
Jeg mener at du kan ændre dine koder under kontrolpanelet eller kontakt livesupporten på one.com

///McCookie

"windscape >> det er meget muligt, at min kode er fucked up, men det er sket efter at one.com har opdateret deres MySQL fra 4.0.24 til MySQL 4.1.11.
Alle mine sider virkede igår og virker ikke idag. Om man så kan betegne det som fucked up kode vil jeg lade eksperter afgøre"
-- Ja, det er NETOP pga. din kode er forkert.

Jeg arbejder til dagligt under 10 forskellige system setups, men min grundlæggende kode virker altid.
Og hvis problemet er som erik foreslår, så er det jo også din egen skyld.

Du kan ALDRIG give din hosting skylden for en kodefejl.. du kan kun give dem skylden hvis de slår noget fra som normalt var slået til.

Debug din SQL streng, og fejlen burde være nem at spotte.. *sigh*

Adgangskoder blev ændret et par minutter efter idiotisk indlæg (19:27:12)

Jeg har nu en php info hér: http://www.ryesgade60.dk/php_info.php, men den siger mig ikke vildt meget. Kigger lige på "register globals" i admin.

Ser "off" ud for mig. Godt gået, one.com, hvis det er default indstillingen :)

register_globals    Off    Off

I den kode du viser, kan jeg ikke lige se du bruger det, men hvem ved...

Der er forskelle mellem et ikke-opdateret one.com domæne og et opdateret:
på den jeg linker til står;
  - System  Linux srv53 2.6.12.6-vs2.0 #1 SMP Wed Oct 12 12:28:03 CEST 2005 i686
          mbstring.internal_encoding | ISO-8859-1 | no value
          Active Persistent Links  | 0
          Active Links            | 0

på et andet, der stadig kan arbejde med min kode står:
  - System  Linux srv15 2.6.12.6-vs2.0 #1 SMP Wed Oct 12 12:28:03 CEST 2005 i686 
          mbstring.internal_encoding  | no value  | no value
          Active Persistent Links  | 1
          Active Links            | 1

Herudover er der naturligvis forskelle på domænenavnve, serveradresser, etc. Men det er umiddelbart disse 4 poster der adskiller sig.
Og lad mig gentage; efter one.com opdatering af det domæne jeg linker til hér, blev ALLE MINE TABELLER AUTOMATISK SAT TIL SVENSK (!) KOLLATION. Foreløbig er jeg ikke overbevist om at det er min kode der er latterlig. Den er nok oldschool, rodet, grisset med mere, men jeg forstår ikke hvorfor en ny og bedre MySQL-version ikke skulle kunne benytte samme kode, hvis det kun handler om (unicode) sprog?

Det er nok heller ikke derfor. Du ville højst kunne riskere sjove tegn på skærmen, eller en anden sorteringsrækkefølge.

OK folkens. Løsningen på problemet ´
- når man ser bort fra at redigere i millioner af inkluderede funktioner, jeg ikke selv har lavet -
...er opdatering.

Selvom produktet ikke længere udbydes (efter at ADOBE har opkøbt skaberne) er det lykkedes mig at finde en nyere udgave. Og nu virker det hele igen. Det vil sige, at jeg skal alligevel til at rode med alle siderne igen, men det kan ordnes på kort tid (pr. styk).

Så tusind tak for alle de gode idéer og henvendelser... og knap så meget tak for de mindre gode. Arrogant overlegenhed i et forum som dette virker en kende letkøbt, forekommer det mig :-(