首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

错误:关系"abc.emp_audit“不存在。当我在所有对象中添加架构名称时。它在没有模式的情况下工作得很好

这个错误是由于在查询或操作数据库时,引用了一个不存在的关系(表)"abc.emp_audit"。当你在所有对象中添加架构名称时,它在没有模式的情况下工作得很好。

在数据库中,关系(表)是用于存储和组织数据的基本结构。架构名称是用于在数据库中区分不同的对象(表、视图、函数等)的命名空间。当你在查询或操作数据库时,如果没有指定架构名称,数据库会默认在当前架构中查找对象。如果你在所有对象中添加了架构名称,那么数据库会根据指定的架构名称来查找对象。

在这种情况下,错误提示表明"abc.emp_audit"这个关系(表)在数据库中不存在。可能的原因是:

  1. 你可能没有正确创建或导入"abc.emp_audit"这个关系(表)。
  2. 你可能在查询或操作数据库时错误地引用了"abc.emp_audit"这个关系(表)。
  3. 你可能在查询或操作数据库时指定了错误的架构名称。

为了解决这个错误,你可以采取以下步骤:

  1. 确认你已经正确创建或导入了"abc.emp_audit"这个关系(表)。你可以通过查看数据库中的对象列表或执行相关的DDL语句来验证。
  2. 检查你的查询或操作语句,确保正确引用了"abc.emp_audit"这个关系(表)。你可以使用数据库提供的工具或命令行界面来执行查询或操作。
  3. 如果你在查询或操作语句中指定了架构名称,确保指定的架构名称与实际的架构名称匹配。你可以查看数据库中的对象列表或执行相关的DDL语句来确认。

总结起来,这个错误提示表明你在查询或操作数据库时引用了一个不存在的关系(表)"abc.emp_audit"。通过确认关系(表)是否正确创建或导入,检查查询或操作语句的正确性以及确认架构名称的准确性,你可以解决这个错误。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

如何设计一个JavaScript插件系统

插件是库和框架的常见功能,并且有一个很好的理由:它们允许开发人员以安全,可扩展的方式添加功能。这使核心项目更具价值,并建立了一个社区——所有这些都不会增加额外的维护负担。太好了!...,插件通常分为两个部分: 要执行的代码 元数据(例如名称,描述,版本号,依赖项等) 在我们的插件中,exec 函数包含我们的代码,name 是我们的元数据。...首先,我们将插件与“核心(core)”计算器方法(如 plus 和 minus)分开,方法是将其放入自己的插件对象中。将我们的插件存储在plugins 对象中可使我们的系统更安全。...我们还有很多工作可以改善我们的系统。 如果插件作者忘记定义名称或返回值,我们可以添加错误处理以通知插件作者。...但是,如果它还可以注册某些生命周期事件的回调(例如当计算器将要显示值时)怎么办?或者说,如果有一个专门的地方让它在多个交互中存储一段状态呢?这会不会开辟一些新的用例? 我们还可以扩展插件注册的功能。

80020

TypeScript: 请停止使用 any

,我必须编写大量代码,any工作量较少 可能不是,如果编写的代码没有类型,则我们可能需要添加防御性代码,以确保参数和变量具有正确的类型,以使程序能够按预期执行。...有了文档,我可以提供所有上下文 添加类型时,我们会从编译器获得帮助,并且会获得不会随时间推移而衰减的文档,因为如果过时了,我们的代码将无法编译。...我已经通过必要的运行时检查以防御性的方式编写了代码,以确保没有错误 现在可能没有错误,但是除非你有很好的测试覆盖率,否则以后来修改代码的人不会相信他们不是在错误中重构;就好像编译器不会帮你,因为我们说过它不会帮你...,从TypeScript中删除 any,立即打开PR 让我们深吸一口气, any 它在正确的情况下非常强大且有用。...它使编译器过时了,我们告诉编译器:我不需要你的帮助 我们放弃了在编写代码时记录代码的机会 我们的第一道防线被攻破了 在动态语言中,我们假设事物可以有 any 类型,我们采用的模式遵循这个假设。

1.2K21
  • 设计一个JavaScript插件系统

    ,插件通常分为两个部分: 要执行的代码 元数据(例如名称,描述,版本号,依赖项等) 在我们的插件中,exec 函数包含我们的代码,名称是我们的元数据。...同样的, squared 函数通过产生副作用发挥作用。这在 JavaScript 中并不少见,但感觉不是很好 —— 特别是当其他插件可能在处理同一内部状态时。...首先,我们将插件与“核心”计算器方法(如plus和minus)分开,方法是将其放在自己的插件对象中。将插件存储在一个plugin对象中可以使我们的系统更安全。...如果插件作者忘记定义名称或返回值,我们可以添加错误处理以通知插件作者。像QA开发人员一样思考并想象我们的系统如何崩溃,以便我们能够主动处理这些情况。 我们可以扩展插件的功能范围。...没有什么比让每个人都重写他们的插件更痛苦的了,因为你需要更改插件架构。这是一种失去信任并阻止人们在将来做出贡献的快速方法。 结论 从头开始编写好的插件架构很困难!

    74941

    C# API中的模型和它们的接口设计

    在传统的MVC、MVP、MVVM、Web MVC这些UI模式中,模型是一个公共元素。虽然有很多文章讨论这些架构中的视图和控制器,但几乎无一涉及模型。...string Error {get;}:这个属性有三个用途: 报告对象级别的错误 报告所有属性级别的错误 通过返回一个空字符串来表示不存在错误 string this[string columnName...清除错误:从对象中删除所有已触发的验证错误。 对于这种模型,模型对象将从初始状态开始。如果它在显示给用户之前已经包含了部分值,则应该在向用户显示之前调用清除错误的方法。...由于没有UI框架使用这个接口,所以没有理由支持它或IValidatableObject接口。 属性变更通知 属性变更通知在很多情况下都很有用,不过更常见的是与MVVM设计模式相关联。...Invoke(this, new PropertyChangedEventArgs(nameof(Name))); }} 在上面的示例中,即使没有不存在任何侦听者,每个属性变更通知让然会分配一个新对象来保存属性名称

    1.7K20

    Python 架构模式:引言到第四章

    (即使我们将订单引用添加到OrderLine类中,它也不是唯一标识线路本身的东西。) 每当我们有一个具有数据但没有身份的业务概念时,我们通常选择使用价值对象模式来表示它。...⁵ 对于实体和价值对象,思考__hash__的工作方式也很重要。这是 Python 用来控制对象在添加到集合或用作字典键时的行为的魔术方法;你可以在Python 文档中找到更多信息。...每当我们添加一个新的领域对象想要检索时,我们将不得不在我们的存储库类中写入几行代码,但作为回报,我们得到了一个简单的抽象层,我们可以控制。...与存储库模式和FakeRepository结合使用时,我们有了一种很好的方法来以比领域层更高的级别编写测试;我们可以在不需要使用集成测试的情况下测试我们的工作流程(详见第五章以获取更多关于此的阐述)。...服务层与session对象紧密耦合。在第六章中,我们将介绍另一种与存储库和服务层模式紧密配合的模式,即工作单元模式,一切都会非常美好。你会看到的! ¹ 服务层服务和领域服务的名称确实非常相似。

    52110

    怎样设计一个 JavaScript 插件系统

    将我们的插件存储在一个 plugin 对象中可以使系统更加安全。现在此插件访问 this 时看不到 BetaCalc 的属性,只能得到 betaCalc.plugins 属性。...其次,我们实现了一个 press 方法,该方法按名称查找功能对应的函数,然后调用。现在,当我们调用插件的exec 函数时,会把计算器当前的值(currentValue)传给它,并得到新的值。...从本质上来说,新增加的 press 方法把所有的计算器功能都转换为了纯函数(pure functions),它们返回结果只依赖其参数,并且在执行过程中没有副作用。这样做有很多好处: 简化了API。...如果插件作者忘了定义名称或返回值,可以通过添加错误处理机制来通知插件作者。需要像 QA 那样思考问题,并想象在什么情况下会使我们的系统崩溃,这样才能使我们为这些情况添加容错机制并避免崩溃。...总结 从零开始写一个好的插件架构是非常困难的,你必须考虑并权衡很多因素来构建满足所有人的需求。它足够简单吗?足够强大吗?可以长期工作吗? 这种努力的付出是值得的,拥有一个好的插件系统可以帮助所有人。

    83810

    这两个设计决策,让 Kubernetes 变得可怕

    我不会在这里尝试就它是否实现了该目标(或者它在实践中何时实现或没有实现该目标)发表意见;只需将它视为一个要解决的问题,我就能理解所遇到的许多设计决策,这样的视角应该是可行的。...举两个具体的例子: 错误被延迟 在 Kubernetes 中创建对象(例如 pod)时,通常只是在配置存储中创建一个对象,断言该对象的期望存在。...如果由于资源限制(集群已满负荷)或由于对象在某些方面内部不一致(你引用的容器映像不存在)而无法真正满足该请求,那么一般来说你在创建时不会看到该错误。...或者它虽然是可能的,但却是一个罕见的用例,因此控制器的作者忘了实现它。对于 Kubernetes 中的核心内置原语,你可以很好地保证它们经过良好的测试和实践检验,并且应该能够很好地工作。...但是当你开始添加第三方资源、管理 TLS 证书或云负载均衡器或托管数据库或外部 DNS 名称时(Kubernetes 的设计倾向于将你推向这个方向,因为它更希望成为你整个堆栈的真相来源),你会在人迹罕至的道路上徘徊不前

    23730

    Webpack 5 正式发布

    在 Webpack 4 中,由于 package.json 中的"sideEffects"标记不正确,这种优化导致了一些只在生产模式下出现的错误。...在很多情况下,开发和生产都是在不同的操作系统上进行的,文件系统的大小写敏感度不同,所以 Webpack 5 增加了一些奇怪的大小写的警告/错误。...这与模块合并很好地结合在一起,即多个模块被合并成一个模块。在最好的情况下,根本不需要运行时代码。...大多数模块、所有的依赖关系和一些错误都已经这样做了。 迁移:当使用自定义模块或依赖关系时,建议将它们实现成可序列化的,以便从持久化缓存中获益。...现在它在只基于原生的 Node.js 中的 fs,这意味着在 webpack 中已经没有原生依赖了。 它还能在监听时捕捉更多关于文件系统的信息。

    1.3K10

    阔别两年,webpack 5 正式发布了!

    开发与生产的一致性问题 我们试图通过改善两种模式的相似性,在开发模式的构建性能和避免仅在生产模式的产生的问题之间找到一个很好的平衡点。...在 webpack 4 中,由于 package.json 中的"sideEffects"标记不正确,这种优化导致了一些只在生产模式下出现的错误。...这与模块合并很好地结合在一起,即多个模块被合并成一个模块。在最好的情况下,根本不需要运行时代码。...它有一个可选的语义,所以那些应该被序列化的类需要被明确地标记出来(并且实现它们的序列化)。大多数模块、所有的依赖关系和一些错误都已经这样做了。...现在它在只基于原生的 Node.js 中的 fs。这意味着在 webpack 中已经没有原生依赖了。 它还能在监听时捕捉更多关于文件系统的信息。

    1K31

    阔别两年,webpack 5 正式发布了!

    开发与生产的一致性问题 我们试图通过改善两种模式的相似性,在开发模式的构建性能和避免仅在生产模式的产生的问题之间找到一个很好的平衡点。...在 webpack 4 中,由于 package.json 中的"sideEffects"标记不正确,这种优化导致了一些只在生产模式下出现的错误。...这与模块合并很好地结合在一起,即多个模块被合并成一个模块。在最好的情况下,根本不需要运行时代码。...它有一个可选的语义,所以那些应该被序列化的类需要被明确地标记出来(并且实现它们的序列化)。大多数模块、所有的依赖关系和一些错误都已经这样做了。...现在它在只基于原生的 Node.js 中的 fs。这意味着在 webpack 中已经没有原生依赖了。 它还能在监听时捕捉更多关于文件系统的信息。

    1.7K32

    为什么我使用 GraphQL 而放弃 REST API?

    但你真能负担得起在所有项目中都做到这样吗?当你的团队在冲刺期间决定重命名或重新安排对象字段时,你能负担得起上线/api/v1.99端点的成本吗?...在客户端或服务器上的所有验证逻辑,你确定都是正确的吗?理想情况下,你希望它在两边都得到验证,对吧?维护所有这些自定义代码非常有趣。或者保持 API JSON 模式是最新的。...你是否总是希望一次获取所有相关的项目?可能不需要,但是还需要添加更多的查询参数。也许你不想一次获取所有对象字段。...在大多数情况下,向 GraphQL API 发出的每个请求要么是没有副作用的Query实例,要么是会修改存储在服务器上的对象的Mutation实例。...但是,你几乎从来都不需要接触如此低的抽象层。 总体来说还不错:我们已经解决了类型级别的验证问题,分页看起来也不错,并且在需要时可以轻松地遍历实体关系。

    2.3K30

    软件架构编年史:事件驱动架构

    当组件需要协作时,比如组件“A”需要触发组件“B”中的某段逻辑,自然而然的方法就是简单地让组件 A 调用组件 B 的一个对象的方法。...组件 B 会监听事件派发器中这个特殊的事件,在该事件发生时做出响应。 有一点要特别指出,这种模式有一个特点,事件只会携带最少的数据。...事务日志 上面这种方法大多数情况下都可以工作得很好,但是如果我们想要知道实体是如何到达这个状态的呢(比如,我们想知道银行账号得贷项和借项)?这种方法就做不到了,因为我们知保存了当前状态!...所有的提交记录就是事件存储,而源代码树的工作副本就是系统状态。...相反地,我们应该在事件流中创建一个事件,撤销我们想要删除的事件。这个过程被称作逆转事务,它不仅要将实体带回期望的状态,还要留下展示该对象在给定时间点处于该状态的轨迹。 保留数据还会带来架构上的好处。

    76340

    微服务中的几种失败路径

    当我开始探索他们的代码库时,我不断在每个仓库中都看到相同的代码。这个应用程序的对象模型是相当复杂的,有大约 20 个类,其中一些类有 70 个字段。这是一个复杂的模式。...但如果领域模式仍然是共享的,耦合依旧无法避免。复制对象代码并不能消除耦合,它只是消除了编译时检查的可能性。一个字段名改变了仍然会破坏所有事物,但这种破坏直到运行时才会发生。...在系统中还会有其他许多元素,这些元素可能是我们在设计真正干净的微服务架构时没有考虑到的。我们对业务逻辑感到非常兴奋,而忘记了前端和后端的事物,以及所有的胶水。在企业架构中胶水尤其常见,而且非常粘手。...某人正在跟踪一个电子表格,上面有所有微服务之间的依赖关系,这些微服务的耦合度超出了应有的水平。当然,发布的日期也必须是黄道吉日才行。当我们选择微服务架构时,可并没有想过会陷入这样的困境!...通常情况下,我们如此害怕发布的原因在于,在发布过程中需要涉及大量人工工作。尤其重要的是,真正能给我们带来信心的测试并不是自动化的,所以我们需要做大量的工作来弄清楚应用程序是否能正常工作。

    34230

    python简明笔记

    写入到文件中的任何数据将自动添加到末尾 文件关闭 close()方法完成文件按关闭 始终确保你显式关闭每个打开的文件,一旦它的工作完成你没有任何理由保持打开文件。...Python的错误其实也是class,所有的错误类型都继承自BaseException,所以在使用except时需要注意的是,它不但捕获该类型的错误,还把其子类也“一网打尽”。...多重继承 在设计类的继承关系时,通常,主线都是单一继承下来的,但是,如果需要“混入”额外的功能,通过多重继承就可以实现,这种设计通常称之为MixIn。...__getattr__ 正常情况下,当我们调用类的方法或属性时,如果不存在,就会报错。...__call__ 一个对象实例可以有自己的属性和方法,当我们调用实例方法时,我们用instance.method()来调用。能不能直接在实例本身上调用呢?在Python中,答案是肯定的。

    2.2K90

    坚持还是放弃,Go语言的“美好与丑陋”解读

    这可能会带来更高的 CPU 成本,但是在水平可伸缩的架构(horizontally scalable architecture)中通过添加更多的机器这是易于解决的。...自定义类型 我喜欢自定义类型,而且我恼怒/害怕一些情况,就好像当我们来回传一个字符串型或者 long 型的持久化对象标识符的时候。...完成配置是很痛苦的,而你在开发过程中从没有考虑过它,直到你添加一个新的导入或者简单地想把你的一个团队成员的一个分支拉到你的 GOPATH 中时... 现在让我们回到代码上吧。...混乱的错误管理 在 Go 中你需要快速学习的是错误处理模式,因为反复出现: ? 由于 Go 声称不支持异常(虽然它支持异常),但每个可能以错误结尾的函数都必须有 error 作为其最终处理结果。...我发现他们实际上是危险的救急: ? 以上的检查错误一直令人痛苦,这种模式忽略了写入时的序列错误,而是在写完时才提示。 因此,任何执行的操作都会在执行完错误后执行。 如果这些比分片更昂贵呢?

    1.7K41

    代码整洁之道【笔记】

    4.如果说空白行隔开了概念,靠近的代码行则暗示了它们之间的紧密关系 5.除非有很好的理由,否则就不要把关系密切的概念放到不同的文件中,实际上,这也是避免使用protected变量的理由之一,应避免迫使读者在源文件和类中跳来跳去...面向对象代码便于在不改动既有函数的前提下添加新类 * 过程式代码难以添加新数据结构,因为必须修改所有函数。...面向对象代码难以添加新函数,因为必须修改所有类 C.得墨忒耳律 1.得墨忒耳律(The Law of Demeter):模块不应了解它所操作对象的内部情形,意味着对象不应通过存取器曝露其内部结构,因为这样更像是曝露而非隐藏其内部结构...(要使用的API)的容易而不会影响其他工作的途径 2.学习性测试确保第三方程序包按照我们想要的方式工作 D.使用尚不存在的代码 1.编写我们想得到的接口,好处之一是它在我们控制之下,有助于保持客户代码更可读...“组件”即便在不了解全局时也能有效地运转 B.将系统的构造与使用分开 1.构造与使用是非常不一样的过程 2.软件系统应将启始过程和启始过程之后的运行时逻辑分离开,在启始过程中构建应用对象,也会存在互相缠结的依赖关系

    99730

    领域驱动设计 (DDD) 总结

    4.1 关联的设计 关联本身不是一个模式,但它在领域建模的过程中非常重要,所以需要在探讨各种模式之前,先讨论一下对象之间的关联该如何设计。...;但是如果由于参数无效等原因不能创建出期望的对象时,应该抛出一个异常,以确保不会创建出一个错误的对象。...这种方法理论上不需要 ORM 框架的支持,对领域模型没有侵入性,同时也很好的支持了工作单元的模式; 基于 AOP 思想 类似于 Spring AOP 的思想,通过代理的方式进行拦截。...这种方法使工作单元知道需要持久化哪些对象,对领域模型的侵入性不大,同样能很好的支持工作单元模式; 八....这种模式建立在团队之间友好合作和支持的情况下。

    3.1K51

    Java之父接受Evrone专访:您需要的软件可靠性越高,静态类型语言的帮助就越大

    他试图在不破坏更改的情况下发布这个版本,看看会发生什么。不会破坏任何内容的主要语言版本。我知道 Java 对不破坏事物持谨慎态度。所有语言都在没有不兼容的情况下发展是一个好主意吗?...Grigory:25 年前,当我开始自己的软件开发职业生涯时,我编写了大量 C 和 C++ 代码。我记得这些每月发生一次的神秘指针错误。调试这样的错误很痛苦。...因此,当我们查看 JavaScript 和 Python 等动态类型语言时,它们没有足够的推理框架来解决这个问题,因为它们不一定知道任何东西的类型;他们只是在猜测。...如果您在工业环境中,我一生中的大部分时间都在那里工作,那么工作一次只会有点用处。它必须每次都有效。一次工作和每次工作之间的差异是巨大的。因此,如果它只需要工作一次,那么更动态的语言工作得相当好。...效果很好, 当我在 70 年代初发现 Simula 时,它有一种自然的风格。你只是编程,你可以把你的计算看作是一个独立的东西。其他事物是否与它交织对您来说是透明的。

    58730

    Python 架构模式:第十章到结语

    因此,当它们失败时,发送者需要接收错误信息。 事件由一个参与者广播给所有感兴趣的监听器。当我们发布BatchQuantityChanged时,我们不知道谁会接收到它。...它在前面的示例中没有显示出来,而且当处理连接的对象时,您可以显式请求急切加载以避免这种问题。 除了SELECT N+1,您可能还有其他原因希望将状态更改的持久化方式与检索当前状态的方式解耦。...您的每个用例都需要有一个命令式的名称:例如,应用计费费用、清理废弃账户或提高采购订单。 在我们的情况下,大多数用例都是经理类的一部分,名称如创建工作空间或删除文档版本。...很难在不跨越整个代码库进行寻宝之旅的情况下理解每个操作的含义。将所有逻辑汇总到一个方法中,并使用 UoW 来控制我们的事务,使系统更容易理解。 提示 如果在用例函数中存在重复,也没关系。...例如,在新模型中,当我们锁定一个账户时,我们可以首先查询所有受影响的工作空间。通过SELECT *id* FROM *workspace* WHERE *account_id* = ?。

    29810

    Unity基础教程系列(十二)——更复杂的关卡(Spawn,Kill,and Life Zones)

    哪种类型的刚体无关紧要,因此让我们将其添加到区域中,以使形状尽可能简单。 在某物上添加刚体会使它像物理对象一样工作,其中就包括受重力影响。...2.7 形状碰撞器 当我们使用碰撞器处理区域时候,需要看下我们的形状所使用的碰撞器。简单的形状很好,但是复杂的形状每个都由多个对象组成,所以也会有多个碰撞器。...只是对象不会更新,但这一点我们很快就会注意到。在设计一个关卡时,删除对象是很常见的,如果对象已经被添加到数组中,就会产生麻烦。丢失的对象会产生空指针,这些空指针将在游戏模式下生成异常。 ?...将其列入List将表明在运行过程中进行更改是可以的,这不是我们设计的方式。 通过使用标签调用GUILayout.Button,在我们的自定义检查器中的错误消息下方添加一个按钮。...现在,可以在选择资产和场景对象混合的同时调用我们的菜单项,这没有任何意义。理想情况下,仅当选择游戏对象以外的任何东西时才应启用菜单项。我们可以通过验证方法来强制执行。

    1.7K51
    领券