Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You can tell VB6 to reuse GUID's (IID's CLSID's LIBID's etc.) by changing the compatbility setting of the project to from "No Compatbility" to "Binary Compatibility". You can find these settings under Project-><em>Your-Project</em> Properties. The compatibility setting is on the Component tab of the Project Properties window. There are three choices:</p> <ul> <li>No Compatibility </li> <li>Project Compatibility </li> <li>Binary Compatibility</li> </ul> <p>Here's what <a href="http://support.microsoft.com/kb/161137" rel="noreferrer">MSDN</a> says about them:</p> <blockquote> <p><h3>No Compatibility</h3><br/> With this setting, no compatibility is enforced. Visual Basic creates new Interface IDs and Class IDs every time you build or compile your project. Each version built can only be used with applications created to work with that specific build of the component.</p> <p><h3>Project Compatibility</h3><br/></p> <p>With this setting, you can make your project compatible to a specific component project. While new type library information is generated, the type library identifier is maintained so that test projects can still refer to the component project. This setting is for maintaining compatibility during testing. Therefore, once the component is released, it behaves the same as the No Compatibility setting.</p> <p><h3>Binary Compatibility</h3><br/></p> <p>When you compile your project, Visual Basic only creates new Class and Interface IDs when necessary. It preserves the class and interface IDs from the previous version(s) so that programs compiled using an earlier version will continue to work. If you are making a change that will result in an incompatible version, Visual Basic will warn you. If you want to maintain compatibility with older, released versions of an ActiveX component, this is the setting you need to use.</p> </blockquote> <p>It sounds like you are currently compiling with <strong>No Compatibility</strong>. As the MSDN article states, you need to use <strong>Binary Compatibility</strong> to keep newer versions of your components compatible with older versions. You can do this now by doing the following:</p> <ul> <li><p>Compile each project once with <strong>No Compatibility</strong></p></li> <li><p>Save these "clean" versions to a folder that people doing the builds can easily access, such as network share, or, put them in source control.</p></li> <li><p>Go back and change all the projects to "Binary Compatibility" and point the "Compatible File" to the corresponding version that you just saved on the network/in source control (do not point the compatible file to the same path that you are compiling the project to. The compatible file should be a separate copy of the original component that won't change. It only exists so that VB can copy the ID's from that file into your project when you recompile it).</p></li> </ul> <p>Every time you recompile your projects, they will reuse the GUID's from the compatible (original) versions of the components.</p> <p>EDIT: As Joe mentioned in the comments, you also have to recognize when your class interfaces have changed (that is, when an interface changes enough that you can longer maintain binary compatibility with the previous versions). When this occurs, you want to make a clean break from the previous versions of the components: recompile a new "clean" version (i.e. with No Compatibility) and use that new version as your compatible file in future builds. However, it's important to note you should only start over again when your class interfaces (properties and methods) change. In fact, VB will warn you when a project is no longer compatible with the previous version of the component. </p> <h3>If you want to live on the edge...</h3> <p><br/> Where I work, we tend to (ab)use No Compatibility on most of our projects, even though it's not really the correct way to do things (you <em>should</em> use Binary Compatibility). At our company it was acquired laziness, because we have an automated build tool that compiles all of our projects for us, and one of the main features of the tool is that is can automatically repair broken project references between projects. Since the build tool fixes this for us, there is less incentive to use Binary Compatibility.</p> <h3>Why Binary Compatibility is better (or...why you shouldn't do what we do)</h3> <p><br/> A few reasons why Binary Compatibility is usually the better choice:</p> <ul> <li><p>Microsoft says so</p></li> <li><p>If all your components are binary compatible with previous releases of your software, you can easily recompile a single component and redistribute it to your customers. This makes bugfixes/patches easier to deploy. If you use No Compatibility on your projects, you will have to recompile and redistribute your entire application every time a small patch needs to go out, because the newer components (probably) won't work with the older components.</p></li> <li><p>You are doing your part to uphold the COM standard: In COM, class ID's and interface ID's are supposed to uniquely identify a class or interface. If your classes and/or interfaces haven't changed between builds, then there is no reason to generate new ID's for those classes and interfaces (in fact, then the same class would have multiple ID's). Binary Compatiblity allows you to maintain the same ID's across builds, which means you are being a good citizen and following COM conventions.</p></li> <li><p>Less Registry noise. If you are always deploying new components to customers that aren't binary compatible with old versions, each new version will add new information to the registry. Each new interface and class ID has to registered, among other things. If you keep everything Binary Compatible, then an installer only has to add the registry keys in one place, since your class ID's and interface ID's won't change.</p></li> <li><p>If you are exposing a public API or component that other third party applications are consuming, you will definitely want to use Binary Compatibility so that you don't break third party software that depends on your code.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POBuildprocess for ActiveX / COM / VB6 enterprise projects
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMike Spross
    1. USMike Spross
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1, absolutely right, should use binary compatibility. But you then have to have a process in place when you change your interfaces - i.e. rebuild the clean version and save in Source Control again, recognizing when you've broken backwards compatibility.
      singulars
      1. PO
      1. USJoe
    2. CO@Joe: I knew I forgot to mention something. I'll add that in, thanks ;-)
      singulars
      1. PO
      1. USMike Spross
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload