问题描述
使用SQL小提琴查看此简单查询: http://sqlfiddle.com/# ！2/c1eb6/1 .这是一个非常简单的更新查询，为什么会产生错误?我想知道这可能是该网站中的错误吗?
Take a look at this simple query in SQL fiddle: http://sqlfiddle.com/#!2/c1eb6/1. This is a super-simple update query, why is it producing an error? I wonder if could it be a bug in that site?
构建模式:
create table your_table (some_column varchar(50));
insert into your_table set some_column = '30# 11';
insert into your_table set some_column = '30# 12.00';
insert into your_table set some_column = '30# 13.5';
insert into your_table set some_column = 'abdfs';
insert into your_table set some_column = '0000000';
查询:
UPDATE your_table
SET some_column = 1;
推荐答案
对于那些对SQL Fiddle一直在处理的奥秘问题感兴趣的人有一些背景知识:
A bit of background for those interested in some of the arcane issues I've been dealing with on SQL Fiddle:
在JDBC中禁用显式提交，在SQL中检测到它们，或将数据库置于只读状态(dba .se)
从本质上讲，我正在尝试确保小提琴始终保持一致的状态，即使人们与它们玩耍也是如此.我担心的一件事是人们故意破坏数据库，将它们破坏给可能与他们合作的其他人(这种情况以前发生过，但并不幸运).
Essentially, I am trying to ensure that the fiddles always remain in a consistent state, even as people play with them. One thing I've worried about is people intentionally messing with the databases, breaking them for the other people that might be working with them (this has happened before, but not often fortunately).
我已经找到了使每个数据库平台保持干净的方法，但有趣的是，每种方法对于每个平台都是完全不同的.不幸的是，对于MySQL，我不得不求助于最差的选择-仅允许在右侧进行SELECT.这是因为有太多方式可以编写包含隐式提交的查询，而我还没有发现可以防止这种情况在查询端被完全拒绝的情况.我知道这很不幸，但这似乎是必需的.
I've found methods of keeping things clean for each of the database platforms, but interestingly each method is completely different for each platform. Unfortunately, for MySQL I had to resort to the worst option - only allowing SELECTs on the right-hand side. This is because there are too many ways to write queries that include implicit commits, and there is no way that I've found to prevent that from happening short of outright denial on the query side. This is quite unfortunate, I realize, but it seems to be required.
无论如何，这个特定的错误是由于我最近对MySQL逻辑所做的更改而导致的.现在已修复，现在报告预期的错误消息:
Anyhow, this particular bug was a result from a change I had recently made in the logic for MySQL. It is fixed now, and now reports the expected error message:
这篇关于我的SQL Fiddle查询出了什么问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！