Fehler 8155: Keine Spalte wurde für Spalte x von DRVD_TBL angegeben

System: Access 2003 (ADP mit SQL Server 2005)

Dies ist ein Hinweis auf eine fehlerhafte SQL-Anweisung.
Bei mir entstand der Fehler, als die SQL-Anweisung zusammengestückelt wurde:

DoCmd.RunSQL "INSERT INTO myTAB (Wert) VALUES (" & txtFeld & ")"

Alles geht gut, wenn in txtFeld eine ganze Zahl steht. Steht aber eine Kommazahl (z.B. 0,5) drin, dann erscheint in der VALUES-Liste das  Komma, was bedeutet: es werden zwei Werte statt einem übergeben.
Das Komma wird mit folgender Schreibweise korrekt in den SQL-Dezimalpunkt umgewandelt:

DoCmd.RunSQL "INSERT INTO myTAB (Wert) VALUES (" & str(txtFeld) & ")"

Web-Zugriff auf SQL Server

Der SQL Server 2005 erlaubt einer Web-Lösung (hier PHP) keinen Zugriff auf eine DB-Tabelle? Hier ein Beispiel für eine Fehlermeldung:

Warning: mssql_query() [function.mssql-query]: message: Die SELECT-Berechtigung wurde für das 'xxxx'-Objekt, 'yyyy'-Datenbank, 'dbo'-Schema verweigert. (severity 14) in C:\www\zzzz.php on line 26

Lösung:
Es gibt den speziellen Datenbankbenutzer *.IUSR_* (* für lokale Bezeichnungen). Diesen Benutzer muß man nicht selbst anlegen.
Über die Datenbankeigenschaften, Register Berechtigungen muß man ihm die Rechte für CONNECT, DELETE, INSERT, SELECT, UPDATE (soweit nötig) eintragen. Achtung, bei den Eigenschaften des Nutzers selbst ist das weder sichtbar noch möglich.

Hintergrund:
Der Nutzer IUSR - der bei Microsoft auch in anderen Kontexten existiert - ist speziell für anonyme Internetbenutzer gedacht, wie sie typischerweise bei Webbenutzung auftreten. Das heißt nicht, daß jeder Nutzer nun per DELETE einfach in der Datenbank irgendwas löschen kann, sondern nur, daß dies die Oberfläche darf, die der Nutzer benutzt. Nur wenn das PHP-(/ASP...)Programm von sich aus ein DELETE schickt, wird dies ausgeführt.
Beachten: die berühmte SQL-Injection (Es darf dem Benutzer nicht möglich sein, irgendwo einen SQL-Befehl einzutragen, der dann ungewollte Operationen ausführt - s. http://de.wikipedia.org/wiki/SQL-Injection).

Unterformular zeigt leeres Rechteck

Das Problem taucht in Accessprojekten (2002/2003) auf Basis SQL Server 2005 auf.

Die Datenherkunft darf in der ORDER BY-Klausel keine Bezeichnungen wie "XY.ID" enthalten. Erlaubt sind in dieser Klausel nur reine unqualifizierte Feldnamen wie "ID".

Hilfen:
Bearbeite die ORDER BY-Klausel für diesen Zweck in der SQL-Box, nicht per Abfrageassistent (er fügt den Tabellennamen bzw. -alias wieder zu).

Weise allen nicht eindeutigen Feldnamen, die in ORDER BY vorkommen, einen Alias zu und schreibe diesen hinter ORDER BY.

Notfalls eine Tabelle tabelle1 durch eine Unterabfrage ersetzen a la
...
FROM (Select ID as XYID, ... From tabelle1) AS XY
...

Verbindung eines ADP zur Laufzeit festlegen

Folgende VBA-Prozedur weist dem ADP eine neue Verbindung zu:

Public Sub OpenADPConnection(ByVal strUser As String, ByVal strPassword As String)
Const strCONNECTION_STRING As String ="Provider=SQLOLEDB;Data Source=deinServer;Initial Catalog=deineDatenbank"
CurrentProject.OpenConnection strCONNECTION_STRING, strUser, strPassword
If Not CurrentProject.IsConnected Then
MsgBox "Es konnte keine Verbindung hergestellt werden!"
End If
End Sub

Unangenehmer Effekt:
Access versucht, beim Start einer Anwendung die letzte Verbindung wiederaufzubauen und endet nach Wartezeit mit einem Fehler.
Verhinderung:
Man sollte seine ADP-Anwendung ohne Verbindungsdaten ausliefern und dann, wie oben beschrieben, die Verbindung per VBA beim Start der Anwendung aufbauen.
Die gespeicherten Verbindungsinformationen kann man aus der Anwendung entfernen, indem man per VBA die OpenConnection-Methode ohne Parameter aufruft.

Call CurrentProject.OpenConnection


Danach ist das ADP beim Start verbindungslos und es wird nicht mehr automatisch versucht, eine Verbindung aufzubauen.

SQL Server CONVERT Datetime

Wandle das heutige Datum in Text um:

CONVERT(nvarchar, getdate(), x)

Dabei ergibt sich je nach x:

100: Jul 31 2008 11:49PM
101: 07/31/2008
102: 2008.07.31
103: 31/07/2008
104: 31.7.2008
110: 07-31-2008
112: 20080731
120: 2008-07-31 23:48:13

multipart identifier ... could not be bound

Dies bezieht sich darauf, wenn ein Accessprojekt (ADP) auf einen SQL Server greift, den es  noch nicht kennt (z.B. Access 2003 auf SQL Server 2005).

Mit Multipart identifier ist sowas gemeint wie TabAlias.Feldname (A.ID oder so).
Der Fehler kommt aus dem SQL Server und folgende gefundene Hinweis lauten:
" Oh, yes - is there an IPCode yolumn in the dbo.ClassifiedAd table?
If so, then the optimizer might have processed the explicit join (... JOIN
ON ...) before the implicit one (FROM dbo.ClassifiedAd Ad, dbo.Objects O ...
WHERE ...)"
"Why are you mixing join types (old-style vs. ANSI)? Why do you not use the
alias prefixes on all of your columns? I'll try to re-write this so the
parser understands it, but I have no idea what your table structure looks
like, so I can't fix all the prefixes."
(s.http://www.dbtalk.net/microsoft-public-sqlserver-programming/multipart-identifier-304262.html)

Geholfen hat mir: Ohne Wizzards in der SQL-Anweisung die Tabellenaliase (auch vor den Feldnamen) zu entfernen. Im betreffenden Fall jedenfalls war das möglich ;-)

Nachtrag:
Es genügt, wenn in der ORDER BY- Klausel keine Tabellenqualifizierer stehen (ggf. Spaltenaliase verwenden)

"????????" als Wert eines SQL Server-GUID-Feldes angezeigt

Problembeschreibung
Wenn Sie mit VBA-Code (VBA = Visual Basic für Applikationen) den Wert einer Jet-Replikations-ID oder eines SQL Server-GUID-Feldes (GUID = Globally Unique Identifier) abrufen und anzeigen, erhalten Sie den Wert "????????".
Ursache
Ein GUID ist ein 16-Byte-Datenfeld, das konvertiert werden muss, um von Microsoft Access interpretiert werden zu können.
Lösung
Konvertieren Sie das GUID-Feld mit der Funktion StringFromGUID() in eine Zeichenfolge, damit Access ein GUID-Feld richtig interpretieren und anzeigen kann. Wenn Sie z.B. den folgenden Code auf ein offenes Formular anwenden, in dessen Datensatzherkunft ein GUID-Feld enthalten ist, sehen Sie eine Zeichenfolge hexadezimaler Zahlen in geschweiften Klammern, denen das Wort "guid" vorangestellt ist, wiederum in geschweifte Klammern gesetzt.
Beachten Sie, dass
Debug.Print StringFromGUID(Forms![Formularname]![GUIDFeldname])
etwa so angezeigt wird:
{guid {3B9B63A3-863D-11CF-8CAE-00AA00C0016B}}
aus Microsoft Knowledge Base: 278099 (http://support.microsoft.com/kb/278099/en-us/)

Extraktion und Aufbereitung:

Function °°StringFromGUID(guid As Control) As String
Dim s As String
s = StringFromGUID(guid)
s = Right(s, Len(s) - 6)
°°StringFromGUID = Left(s, Len(s) - 1)
End Function