Kalla på en stored procedure. [värdelöst felmeddelande]

Håller på att knåpa ihop några ganska basic interface mot en databas, varav ett ska skrivas i PHP (som jag inte sysslat med överdrivet mycket innan). Jag har en stored procedure som tar några parametrar och lägger till ett par tupler i databasen, men när jag försöker kalla på den från php så får jag felmeddelandet "Warning: mssql_execute() [function.mssql-execute]: stored procedure execution failed in /[min url här]/create.php on line 25", vilket inte säger mig ett skit mer än att det inte fungerar.

lite kod då...

Tabellerna:


Proceduren:

PHP-koden:

Har användaren $user rättigheter att exekvera proceduren?

Wrappa dina två inserts i en transaktion för att inte riskera tråkigheter.
Använd SCOPE_IDENTITY() snarare än @@IDENTITY för att inte riskera tråkigheter.
Varför lagrar du PIN-koden, och varför lagrar du den som en int? Tänk på att det är ett grovt brott mot PCI-DSS att lagra PIN, och om du anser dig ha behov av det vill jag påstå att din lösning är feldesignad

jag kan exekvera proceduren i SQL Server Management Studio som den usern, så om det inte görs någon skillnad på var den exekveras ifrån så borde jag det.

De andra procedurerna är transactions, vet ej varför denna inte blev det.

vad är skillnaden på @@IDENTITY och SCOPE_IDENTITY()?

Poängen med uppgiften är inte att bygga ett säkert system, utan snarare att designa en någorlunda vettig databasmodell som går att använda, och att skapa lite funktioner/triggers osv för att se fördelarna med dem, därför är inget krypterat osv.

Jag tackar dock för inputen.

SCOPE_IDENTITY() returnerar ID för den rad som senast insertades till en tabell i ditt scope, dvs inom din SQL-anslutning. @@IDENTITY håller ID för den rad som senast insertades till en tabell, globalt sett. Använder du @@IDENTITY och samma procedur (eller någon annan som gör en insert till någon tabell) anropas samtidigt från en annan anslutning till sql-servern, innan du hunnit köra din andra insert-sats, kommer @@IDENTITY att hålla den annan användarens senast insertade ID, vilket skulle få förödande konsekvenser för dig i form av korrupt data
Se http://blog.sqlauthority.com/2007/03/25/sql-server-identity-vs-scope_identity-vs-ident_current-retrieve-last-inserted-identity-of-record/ för mer info.



Testa att anropa mssql_get_last_message() efter att mssql_execute() failar för att försöka få lite mer info om felet...

Och testa att låta mssql_bind() ta hand om detaljerna genom att bara skicka med de tre första parametrarna, de sista tre är ju optional. Kanske främst är den sista, $maxlen, som du ger värdet 10, som kanske kan vara av intresse att mecka med. Default är -1, och dokumentationen säger dessutom:
...Verkar alltså inte vara relevant när det gäller integers.


För övrigt får du aldrig lagra PIN-koden, oavsett hur hårt du krypterar den. Det är såklart godtagbart i en skoluppgift att göra det, men knappast i verkliga livet.

mssql_get_last_message() returnerar "Changed database context to 'mindatabas'. "

Parametrarna är det inget större fel på, jag får samma felmeddelande om jag anropar en procedure utan parametrar, eller om jag tar bort de tre sista.