问题列表 - 第2054页

我是部署桌面应用程序的新手,所以这是我第一次为我的软件构建安装程序.目前,我第一次安装它后运行我的软件,它崩溃了.在那之后,它运行良好.我仍然在调试这个问题,但我注意到安装后和运行软件之前立即重启似乎可以解决这个问题.

某些安装程序要求您在运行软件之前重新启动的常见原因是什么？

另外,为什么有些安装程序需要在完成安装之前重新启动？

提前致谢!

我正在尝试使用LINQ将记录插入到子表中,并且我收到"指定的强制转换无效"错误,该错误与所涉及的密钥有关.堆栈跟踪是:

消息:指定的强制转换无效.

类型:System.InvalidCastException源:System.Data.Linq TargetSite:Boolean TryCreateKeyFromValues(System.Object [],V ByRef)HelpLink:null Stack:at System.Data.Linq.IdentityManager.StandardIdentityManager.SingleKeyManager2.TryCreateKeyFromValues(Object[] values, V& v) at System.Data.Linq.IdentityManager.StandardIdentityManager.IdentityCache2.Find(Object [] keyValues)在System.Data.Linq.IdentityManager.StandardIdentityManager.Find(MetaType type,Object [] keyValues)处于System.Data.Linq.CommonDataServices.GetCachedObject(MetaType type,Object [] keyValues)at at系统.Data.Linq.ChangeProcessor.BuildEdgeMaps()的System.Data.Linq.ChangeProcessor.GetOtherItem(MetaAssociation assoc,Object实例)位于System.Data.Linq.DataContext的System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode) System.Data.Linq.DataContext.SubmitChanges()中的.SubmitChanges(ConflictMode failureMode)

(.....)

以下代码抛出此错误:

 ResponseDataContext db = new ResponseDataContext(m_ConnectionString);
 CodebookVersion codebookVersion = db.CodebookVersions.Single(cv => cv.VersionTag == m_CodebookVersionTag);
 ResponseCode rc = new ResponseCode()
    {
       SurveyQuestionName = "Q11",
       Code = 3,
       Description = "Yet another code"
    };
 codebookVersion.ResponseCodes.Add(rc);
 db.SubmitChanges(); //exception gets thrown here

有问题的表格在两者之间具有FK关系.
父表的列名为'id',是PK,类型为:INT NOT NULL IDENTITY
子表的列名为'responseCodeTableId',类型为:INT NOT NULL.

codebookVersion(父类)映射到表tblResponseCodeTable
responseCode(childClass)映射到表tblResponseCode

如果我直接执行SQL,它可以工作.例如

INSERT …

是否有JQuery UI主题的存储库？

这个问题之所以存在是因为它具有历史意义,但它不被认为是本网站的一个好的,主题上的问题,所以请不要将它作为证据,你可以在这里提出类似的问题.

更多信息:https://stackoverflow.com/faq

您在C++中看到的最酷的元编程实例是什么？
您在C++中看到的元编程有哪些实际用途？

我有一个基类,其中包含一个属性(get方法),我想在子类中覆盖它.我的第一个想法是:

class Foo(object):
    def _get_age(self):
        return 11

    age = property(_get_age)


class Bar(Foo):
    def _get_age(self):
        return 44

这不起作用(子类bar.age返回11).我发现了一个带有lambda表达式的解决方案:

age = property(lambda self: self._get_age())

那么这是使用属性并在子类中覆盖它们的正确解决方案,还是有其他首选方法来执行此操作？

许多语言都有检查Object是否属于某种类型(包括父类)的工具,用'is'实现并使用如下:

if(obj is MyType)

或者稍微繁琐一点,您可以在其他语言中使用'as'关键字进行检查,以进行软类型转换并查看结果是否为null.

我已经多年没有使用过Java而且我正在快速恢复它,但是Java确实可以轻松地做到这一点而无需深入研究Reflection API？

提前感谢您的回答.我在这里和其他地方搜索过,但所涉及的关键词非常通用,即使我确定这有一个简单的答案,谷歌搜索它很难.

我正在使用需要通过串行通信的外围设备.我可以使用HyperTerminal发送命令,但现在我需要编写程序,让我在没有HyperTerminal的情况下完成它.有人能指点我到一个网站和/或向我展示一个样本问候世界计划让我入门吗？我搜索了许多网站,这些网站给我提供了无法编译/古老的VC6代码.

我正在使用GCC; __FILE__返回当前源文件的完整路径和名称:/path/to/file.cpp.有没有办法file.cpp在编译时获取文件的名称(没有它的路径)？是否可以以便携方式执行此操作？模板元编程可以应用于字符串吗？

我在错误记录宏中使用它.我真的不希望我的源代码完整路径进入可执行文件.

在什么时候你会创建自己的异常类而不是使用java.lang.Exception？(所有的时间？只有在包装外使用它？只有它必须包含高级逻辑？等等...)

背景

我正在研究一个传统的小型企业自动化系统(库存,销售,采购等),它有一个由SQL Server 2005托管的单个数据库和一堆客户端应用程序.主客户端(由所有用户使用)是MS Access 2003应用程序(ADP),其他客户端包括各种VB/VBA应用程序,如Excel加载项和命令行实用程序.

除了60个左右的表(大多数是3NF)之外,数据库还包含大约200个视图,大约170个UDF(主要是标量和表值内联的),以及大约50个存储过程.正如您可能已经猜到的那样,所谓的"业务逻辑"的某些部分被封装在大量的T-SQL代码中(因此被所有客户端共享).

总的来说,系统的代码(包括T-SQL代码)组织得不是很好,可以说是非常重构的.特别是,大多数表的模式都适用于所有类型的重构,小型(如列重命名)和大型(如规范化).

FWIW,我有很长很好的应用程序开发经验(C/C++,Java,VB和诸如此类的东西),但我不是DBA.所以,如果这个问题看起来很愚蠢,现在你知道为什么会这样.:-)

题

在考虑重构所有这些混乱时(当然是以和平方式),我想出了以下想法:

1. 对于每个表,创建一个"包装器"视图,其中(a)具有该表具有的所有列; (b)在某些情况下,根据表的"实际"列有一些额外的计算列.

   这种附加计算列的典型(尽管是简单的)示例是从产品的常规价格和折扣得到的产品的销售价格.

2. 重新组织所有代码(T-SQL和VB/VBA客户端代码),以便只有"包装器"视图直接引用表.

   因此,例如,即使应用程序或存储过程需要从表中插入/更新/删除记录,它们也会针对相应的"表包装器"视图执行此操作,而不是直接针对表.

因此,基本上这是关于通过视图将所有表与系统的其余部分隔离开来.

这种方法似乎提供了很多好处,特别是从可维护性的角度来看.例如:

• 当要重命名表列时,可以在不重写所有受影响的客户端代码的情况下完成.

• 实现派生属性更容易(比使用计算列更容易).

• 您可以有效地为列名称添加别名.

显然,所有这些好处都必须有一些代价,但我不确定我是否看到了潜伏在那里的所有渔获物.

有人在实践中尝试过这种方法吗？有哪些主要缺陷？

一个明显的缺点是维护"包装"视图与其相应表同步的成本(表中的新列也必须添加到视图中;从表中删除的列也必须从视图中删除;等等).但是这个价格似乎很小,而且可以使整个代码库更具弹性.

有没有人知道任何其他更强的缺点？

例如,使用所有这些"包装"视图而不是表格很可能会对性能产生一些不利影响,但这种影响是否足以让人担心呢？此外,在使用ADODB时,即使只基于少数连接表,也很容易获得不可更新的记录集.那么,"包装"观点是否会使事情变得更糟？等等等等...

任何评论(特别是共享的实际经验)将不胜感激.

谢谢!

PS我接下来讨论了"包装"视图的想法:

大观神话

该文章建议避免上述方法.但是......我在文章中没有看到任何反对这个想法的充分理由.恰恰相反,在其创建视图的充分理由列表中,几乎每个项目都是为什么为每个表创建"包装"视图(特别是在遗留系统中,作为重构过程的一部分)如此诱人的原因).

这篇文章真的很古老(1999),所以无论什么理由都好,那么现在可能已经不再好了(反之亦然).使用最新版本的SQL Server和MS Access,听到最近考虑过甚至尝试过这个想法的人真的很有意思......