E
efinix
Hi all,
I'd like to ask you for help. I hope at least one person in the world
has encoutered the same problem before
The problem occurs while executing a DDL command over a MS Access (mdb)
database via MSADO in MS Visual C++:
aConn->Execute(wsSQL.GetString(), NULL, adExecuteNoRecords);
where aConn is IConnection. The SQL command is surely right, I have
successfully tried it in MS Access. The SQL command posted at this
place is:
ALTER TABLE dd_383f05a29863438c830d60f81b95392e ADD
ff_5b1fa7eafe1b4ec8b55342cafb348718 nvarchar(254)
Don't care about those identifiers. Simply a convention here, ff_
followed by 32-byte unique combination for fields.
The problem is data dependent. Under the same user, altering a
different table in the same mdb works fine. The only hint is the number
of fields - the non-working one has 37 fields, the others have less.
I'll be happy if someone could help. Thanks a lot in advance.
Premek
I'd like to ask you for help. I hope at least one person in the world
has encoutered the same problem before
The problem occurs while executing a DDL command over a MS Access (mdb)
database via MSADO in MS Visual C++:
aConn->Execute(wsSQL.GetString(), NULL, adExecuteNoRecords);
where aConn is IConnection. The SQL command is surely right, I have
successfully tried it in MS Access. The SQL command posted at this
place is:
ALTER TABLE dd_383f05a29863438c830d60f81b95392e ADD
ff_5b1fa7eafe1b4ec8b55342cafb348718 nvarchar(254)
Don't care about those identifiers. Simply a convention here, ff_
followed by 32-byte unique combination for fields.
The problem is data dependent. Under the same user, altering a
different table in the same mdb works fine. The only hint is the number
of fields - the non-working one has 37 fields, the others have less.
I'll be happy if someone could help. Thanks a lot in advance.
Premek