So, the solution is fairly simply – I just needed to edit each of the problem forms and re-save under Domino 8.5.1. This seems to clear the problem up immediately. If I then return to an XPage and add a Document data source with that same form, the fields are now all properly displayed in the Data tab in the right sidebar. Hopefully, this post helps someone else who encounters the same problem.

…

dim x as integer, y as integer, res as integer

x = 11

y =4

res = Fix (x / y)

…

The above code would return 2 in the integer variable res.

Of course, if I had used res = x/y, res would have the value of 3, since LotusScript will implicitly round any float when converting to an integer.

Simple, right? But there actually is an operand for performing exactly this type of “integer division”.  You can use the backslash character ( \ ), as in:

…

res = x \ y

…

The backslash operand has been there forever (well, at least back to R5), but how rarely I see it used.

Here are the steps:

• Kick any connected users out of the database.
• Open database in single-user mode by opening Enterprise Manager and right-clicking the database name, and opening the Properties dialog. In the dialog, go to the Options tab, and select the checkbox labeled Restrict Access and then select the radio button labeled Read-Only.
• (Important) Close Enterprise Manager, to be sure SQL Server does not count that session as a connected user.
• Open Query Analyzer and run the system stored procedure named “sp_renamedb”. The proc takes parameters of the old name and new name. For example: “sp_renamedb MyOldDatabaseName MyNewDatabaseName”
• Close Query Analyzer
• Open Enterprise Manager and undo the Restrict Access setting made earlier. (Your database should now be listed under the new name).

That’s it!

Note that this is addressed in 8.0.2 and later.

A few of my favorite articles include Bruce Eckel’s Strong Typing vs. Strong Testing; Paul Graham’s Great Hackers; Eric Lippert’s How Many Microsoft Employees Does it Take to Change a Lightbulb?; and where the lucky stiff’s A Quick (and Hopefully Painless) Ride Through Ruby.

“/” + @webDbName + “/vwResource/myJavascript.js”

An ACL consists of a collection of ACL Entries (and a few other items). To start, let’s look at an ACL entry. An entry contains four basic elements – the name, the access level, a set of roles, and a set of additional privileges (such as “can delete documents”, “can create shared views”, etc.) The name can be either: a user name, a group name, or a “certifier wildcard” (there is also the built-in “Default” name).

So, let’s now imagine a user attempting to access a database. The Domino server first resolves the user and computes a list of all Name and Address (NAB) groups that the user belongs to (this includes resolving membership in nested subgroups, and groups in secondary address books). This step is actually only done once per server and the resulting name/group list is cached. With the user’s name and group list in hand, the Domino server now compares this to the ACL of the database. Any given user may match any number of ACL entries (for example, a user may be listed directly in the ACL, and may be a member of two groups in the ACL and the user’s canonical name may match a certifier wildcard entry). This is all pretty basic – but it’s the next step which is more subtle: how does Domino build your access privileges when you match multiple NAB entries?

Remember those four types of ACL entries? Individual names, groups, certifier wildcards and “default”. Those are important, as the Domino server treats each of these four types as a separate step in the access resolution process, and tries to find a match for this user, in the following order:

1. Individual names
2. Groups
3. Certifier wildcards
4. the “default” entry (which always matches)

At each step, Domino finds all matching ACL entries of the particular type – if there are any matches, the user resolves to the following:

• the highest access level of all matches
• the union of the roles in all of the matches
• the union of the privileges in all of the matches

Once one or matches are found at a given step, DOMINO DOES NOT PROCEED FURTHER. This means, if a user’s name matches an individual name in the NAB, the user will receive that entry’s access level and roles. If the user also matches a group, which has a higher access level, or additional roles, the user WILL NOT receive those privileges. This also means, for example, if the user is in a group with Reader access and the default for the database is Author access, the user will only receive Reader access.

Note:all of the above steps assume that the user is authorized to access the server. If the user is not – for example, if the user’s name is listed in a terminations group (a “deny access” group) which is listed in a server document, then the user will not be allowed access to any database on that server, regardless of the database’s ACL.

Well, the problem relates to views in a SQL Server database. First, a little background. In SQL Server, as in most RDBMS’, views are a mechanism for defining a horizontal and vertical “slice” of a table (or virtual table) – a subset of the columns and rows of data. Views, in theory, are not sorted – the same way that tables are not sorted. If you want a collection of rows from a view, you add an ORDER BY clause to the select statement when you query rows from the view.  SQL Server even enforces this, by preventing creation of a view using a sql query which includes an ORDER BY  clause.

But there are scenarios  (some legitimate, some not so much) in which you may really want to force a sort on the rows of your view. And in SQL Server 2000 and earlier, you could do this via a bit of a hack – by defining your view query using “select TOP 100 PERCENT”.

An aside: Why would that work? Well, consider the case in which your view should only include the first 25% percent of the rows in a table – well, the “top 25%” only makes sense in the context of a result set which is sorted, right? (What does the “top 25%” from my employee table mean? The top by alphabetical name? By age? By hat size?) So, SQL Server allows this as a special case – you can use an ORDER BY clause in the definition of a view IF you also include a “TOP” phrase in th select clause. So, if you really wanted to force a sort on a view, but you wanted to include all of the records returned by your query, you could “trick” SQL Server into allowing this by adding the “TOP 100 PERCENT.”

So, back to the problem – as of SQL Server 2003, the SQL engine is now (in something of a pre-compile step), removing the TOP 100 PERCENT from any sql queries. And any views which existed in a SQL 2000 or earlier database which was upgraded, which made use of this little trick, would internally have the TOP phrase remove, and then also have the ORDER BY removed. The end result – the same view, but no longer sorted. And if your applications were assuming queries against that view would always be sorted, you now have a broken application.

The “correct” way to resolve this depends on the situation. If possible, the better solution is to add any sorting in the SQL statement which queries the view. But if you do absolutely need the sorting in the view definition, then you can simply change that “SELECT TOP 100 PERCENT” to “SELECT TOP 99.999 PERCENT” or “SELECT TOP 2147483647″ (the max integer size)  - just bear in mind, you are trading one hack for another.

Link: http://code.google.com/p/google-enterprise-connector-notes/