【发布时间】:2017-04-07 04:40:00
【问题描述】:
我正在尝试使用 SQLyog IDE 将表复制到 mySql 中的不同主机/数据库,并且在复制具有 2 个几何字段的表时遇到以下错误:
无法从您发送到 GEOMETRY 字段的数据中获取几何对象
关于此错误还有其他几个 SO 问题,但大多数情况下结论性的答案是,这可能是由于尝试插入空字符串而发生的(this 文章声称几何字段接受 NULL 值)。
在我的情况下,似乎与 NULL 或空字符串无关。
我能够找到因此错误而失败的第一个插入语句。这是它的样子:
(
45,
'2016-01-26 11:44:13',
'a',
'',
0,
0,
3,
100,
1,
1,
-- 1st geometry field
'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0',
-- 2nd geometry field
'\0\0\0\0\0\0\0\0\0\0\0\0\0”¯oM¿”¯oM¿”¯oM¿”¯oM?”¯oM?”¯oM?”¯oM?”¯oM¿”¯oM¿”¯oM¿',
'Geodata',
- 1,
- 1,
1,
- 1
)
另一个插入失败的例子:
(
13853,
'2016-01-26 11:44:13',
'test move',
'',
3,
0,
1251,
0,
1,
0,
'\0\0\0\0\0\0\0kÛÚeA@Lˆv¡@@',
'\0\0\0\0\0\0\0\0\0\0\0\0\0¬Q^ÓdA@Ž„ì$Ø\n@@¬Q^ÓdA@Œ\0c@@)eW^eA@Œ\0c@@)eW^eA@Ž„ì$Ø\n@@¬Q^ÓdA@Ž„ì$Ø\n@@',
'test move',
- 1,
- 1,
2913,
- 1
)
如果我将这些与复制表中执行没有错误的先前插入进行比较(我在目标表中看到它们),前两个如下所示:
(
31,
'2016-01-26 11:44:13',
'Route 1',
'',
2,
0,
3,
0,
1,
1,
'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0',
'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0',
'Geodata',
- 1,
- 1,
1,
- 1
),
(
32,
'2016-01-26 11:44:13',
'Route 2',
'',
2,
0,
3,
0,
1,
1,
'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0',
'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0',
'Geodata',
- 1,
- 1,
1,
- 1
)
我的眼睛可以看到的工作插入和非工作插入之间的唯一区别是后者包含 I-do-not-know-what charset 中的数据,而工作插入则不是(它们的数据似乎是在几何数据类型术语中设置为 null/默认值)。
您可以通过查看它们来判断非工作插件有什么问题吗?
P.S.:一位团队成员声称他通过更改 MySQL 服务器的 my.ini 文件解决了这个问题 - 通过将设置 max_allowed_packet 从 4M(默认)更改为 100M。
# The maximum size of one packet or any generated or intermediate string, or any parameter sent by the
# mysql_stmt_send_long_data() C API function.
max_allowed_packet=100M
我重新启动了我的机器,但没有帮助,不断收到同样的错误。
【问题讨论】:
-
我尝试使用 mySql Workbench 进行转储,转储看起来像 sqlYog 的转储(而工作台的转储显示使用设置 --default-character-set=utf8,以防出现字符集问题,我我不确定 Unicode 是否是 UTF8 的一个选项)。尝试了 Workbench 的 Schema Transfer Wizard,同样的事情,复制此表失败,在相同的记录上出现相同的错误。
-
插入失败的那些记录在复制之前在源数据库/表中看起来是否相同(即奇怪的字符数据)?可能听起来像一个愚蠢的问题,但回答它排除了源数据。
-
您评论的第一个结果是我发现 mySql 工作台对空间类型有更好的内置支持,因为它提供几何类型的可视化显示:二进制格式、文本(支持大约 4 个标准空间类型文本符号)和图像表示。非常感谢你的帮忙。很快就会检查您的建议。