DolphinDB Python API共享表重复创建报错及VSCode执行差异问题

问题背景 #

使用DolphinDB Python API尝试安全创建同名共享表，逻辑为先删除旧的共享表，再创建新表，初始代码如下：

s.run("""
    try {
        undef(`kTable, SHARED);
        share table(1:0, `code`date`close`rate, [SYMBOL, DATE, FLOAT, FLOAT]) as kTable;
    } catch(ex) {
        // ignore if table doesn't exist
    }
""")

首次执行成功，第二次执行时报错：

RuntimeError: in exec: Server response: 'Syntax Error: [line #4]
The shared variable name kTable is already used as a regular variable.

但相同代码在VSCode的DolphinDB插件中逐行执行每次都正常；在Python中拆分为两个独立s.run()调用并添加间隔，有时可成功。报错后检查发现，本地变量和共享变量中均无kTable。

在undef后添加go语句则可稳定执行：

s.run("""
    try {
        undef(`kTable, SHARED);
        go
        share table(1:0, `code`date`close`rate, [SYMBOL, DATE, FLOAT, FLOAT]) as kTable;
    } catch(ex) {
        // ignore if table doesn't exist
    }
""")

疑问 #

1. 为何VSCode逐行执行与Python API批量执行表现不同？
2. “已用作常规变量”具体指什么？明明undef已删除变量，为何share仍认为其存在？

问题解答 #

1. 执行方式差异的原因 #

DolphinDB的代码执行逻辑存在两种模式：

• VSCode插件逐行执行：每一行代码执行完成后，服务器会立即完成变量状态的更新与清理，undef删除共享表的操作会即时生效，后续的share语句在全新的变量状态下执行，不会触发冲突检查。
• Python API批量执行：通过s.run()提交的代码会被当作一个完整的执行块处理。DolphinDB会先对整个代码块做预解析与语法检查，此时undef的实际执行还未开始，编译器仍能检测到kTable的名称残留状态，从而抛出冲突错误。

2. “已用作常规变量”的含义与问题根源 #

• “已用作常规变量”指的是：在当前执行上下文的符号表中，kTable这个名称仍被标记为已占用状态。
• 问题核心在于DolphinDB的预解析与执行顺序：批量执行时，编译器先扫描整个代码块的变量定义，share语句中的kTable会被检测到与之前的共享变量名称冲突；而undef删除变量的操作要等到代码块的运行阶段才会执行，预解析阶段无法感知后续的变量清理动作，因此会误判变量仍被占用。

添加go语句后，会强制将go之前的代码作为独立执行单元立即运行，完成undef的变量清理，后续的share语句在新的执行单元中触发预解析，此时符号表中已无kTable的残留标记，因此可以稳定执行。

内容的提问来源于stack exchange，提问作者Luna