Har fram tills för ett tag sedan använt mig av ett "normalt" tillvägagångssätt med en mysql-databas och ett recordset.
set rs = Server.CreateObject("ADODB.recordset")
rs.open sql, db
Funkar bra.
Bytte nyligen till:
set rs = Server.CreateObject("ADODB.recordset")
rs.CursorLocation = 3
rs.open sql, db
Funkar bra. För det mesta. Dock har jag träffat på fall nu där rs.eof sätts till true. Dock vet jag att så inte är fallet och klistrar jag in frågan i phpMyadmin t.ex så får jag ett antal poster i retur. Funkar även om jag tar bort cursorlocation=3. Vad kan detta bero på?
Han verkar ha råkat ut för samma problem. Men vad menar han med
"2. Alternatively, if I select named fields it works (I havn't tested
with listing all of the fields in the table(s))"
Finns inga datumfält. Alla datum lagras som varchar.
*suckar*
why why why?
(ja jag har precis suttit i 2 timmar och bråkat med en app där alla datum stod i formatet 20090210120300 (detta konverterades till ett hanterbart datum m.h.a en 50 raders funktion))
Han verkar ha råkat ut för samma problem. Men vad menar han med
"2. Alternatively, if I select named fields it works (I havn't tested
with listing all of the fields in the table(s))"
Han menar att han i stället för att skriva så här:
*suckar*
why why why?
(ja jag har precis suttit i 2 timmar och bråkat med en app där alla datum stod i formatet 20090210120300 (detta konverterades till ett hanterbart datum m.h.a en 50 raders funktion))
Ibland så hoppar man in i ett projekt som redan pågått under många års tid (precis som i detta fallet) och saker och ting är som dom är och det är bara för mig att acceptera att det är så och köra på.
Inte för att det direkt stör mej att jobba med datum som lagras som varchar "åååå-mm-dd" men...
298 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
