我有一个到SQL Server的ODBC连接。我需要在Access中处理数据,但这需要很长时间。我的想法是将此数据推送到SQL Server临时表并让SQL Server进行处理。我在Access数据库中有许多传递查询,但不知道如何从Access到SQL Server创建临时表。有没有办法使用查询或VBA代码执行此操作?
答案 0 :(得分:2)
这是我用来调用DB2存储过程的VBA代码片段。相同的技术应该适用于任何DDL语句。为此,请创建传递查询并将CREATE TABLE #tblname...
语句作为其SQL文本。
重要提示:然后打开查询的属性表并将“返回记录”属性设置为“否”。
Dim qdf As QueryDef
Set qdf = CurrentDb.QueryDefs("qry_SP_CHANGE_COLUMN")
qdf.Connect = CurrentDb.TableDefs("SCHEMA_tblName").Connect
qdf.SQL = "call SCHEMA.SP_CHANGE_COLUMN(...)"
qdf.Execute dbFailOnError
qdf.Close
Set qdf = Nothing
注意,您可能不必更改SQL文本。如果表结构永远不会改变,你可以将它留在查询def中。
您面临的挑战是您必须对临时表使用相同的连接进行任何操作。关闭连接的那一刻,你的临时表就会消失,因为它是一个本地临时表,它只对那一个连接可见。如果您有权这样做,可以使用'##',全局临时表来避免这种情况。
答案 1 :(得分:1)
Brian是正确的,您可以使用Pass-Through查询在SQL Server数据库中创建临时表。我通过在Access中创建以下四个传递查询来确认这一点:
[ptq1创建临时表]
BEGIN TRY
DROP TABLE #tblname
END TRY
BEGIN CATCH
-- do nothing
END CATCH
CREATE TABLE #tblname (intInput int, intResult int);
[ptq2填充临时表]
INSERT INTO #tblname (intInput) VALUES (1)
[ptq3做计算]
UPDATE #tblname SET intResult=intInput*2
[ptq4检索结果]
SELECT * FROM #tblname
我可以通过在Access的已保存查询列表中双击它们来连续运行其中的每一个,并且最终查询返回
intInput IntResult
-------- ---------
1 2
这里的绊脚石看起来就像是如何将本地Access表中的数据导入临时表。在VBA中我试过了两个
DoCmd.TransferDatabase acLink, "ODBC Database", "ODBC;DSN=myDB", acTable, "#tblname", "sqlTemp"
和
Set tbd = cdb.CreateTableDef("sqlTemp")
tbd.Connect = "ODBC;DSN=myDb;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=myDb;"
tbd.SourceTableName = "#tblname"
cdb.TableDefs.Append tbd
并且两种方法都失败了,因为他们无法“看到”临时表。 (当我尝试在同一SQL Server数据库中创建指向“真实”表的链接时,完全相同的代码工作。)我还尝试使用tbd.OpenRecordset
创建记录集,而不将TableDef附加到TableDefs集合,并且也失败了。
如果没有指向临时表的链接,那么填充它可能会有问题。我想一个可以使用像......这样的代码。
Set rst = cdb.OpenRecordset("localTable", dbOpenSnapshot)
Do While Not rst.EOF
Set qdf = cdb.CreateQueryDef("", "INSERT INTO [#tblname] (intInput) VALUES (" & rst!intInput & ")")
qdf.Connect = "ODBC;DSN=myDb;Trusted_Connection=Yes;DATABASE=myDb;"
qdf.ReturnsRecords = False
qdf.Execute dbFailOnError
Set qdf = Nothing
rst.MoveNext
Loop
rst.Close
Set rst = Nothing
...将数据从本地表逐行传输到临时表,但对于大量的列来说这可能会非常繁琐,对于大量的行来说可能相当慢。
因此,如果我在你的位置,我会尝试在SQL Server数据库中创建一个“真正的”表。它肯定会让事情变得简单得多。