You run a NewViews server to offer multi-user access to one or more accounting databases. The accounting database files usually reside on the same computer that you use to run the NewViews server. A workstation can always access local accounting databases directly with single-user access but for multi-user access you have to run a server and specify the server on the workstation login row. A server runs as a Windows service so it is always running. For that reason we sometimes refer to the NewViews server as the NewViews service, and these terms can be used interchangeably in most circumstances.
You have to install the server as a Windows service only once, After installing, the server is always running because it is run as a Windows service. If the server computer is re-booted, the NewViews server is restarted automatically. It is also re-started automatically if NewViews itself crashes.
Of course you can run different servers on different server computers so the question is really asking whether you can run multiple servers on the same server computer. The answer is Yes. But each server on the same machine must use a different service name, server database, and port. You can use the NewViews Windows Service Installer to install and start additional services and you can change the service name and server database in its dialog window. The server database is created automatically in the NewViews folder, and the next available port number (above 7890 which is the default) is used automatically. You can open the server later to change the port number if desired.
The previous question showed you can run more than one server on the same computer. But why do this? The answer is that there is no reason to do so. The NewViews server makes complete use of all available computer resources such as multiple processors and available memory. The ability to partition the offered accounting databases using database groups also means there is no reason to run multiple servers for organizational purposes. The ability to run multiple servers on the same computer is retained for backward compatibility to NewViews versions 2.28 and earlier, before 2.29 enhanced server computer resource management and introduced database groups.
These terms can be used interchangeably. A NewViews server is a program that offers remote access to NewViews accounting databases (and to the server itself to monitor and manage accounting databases and connections). The server program runs as a Windows service so Windows runs the server at Windows start-up, and whenever the program crashes, or the computer crashes and re-starts. A Windows service is simply a way to keep a NewViews server (or any program) running.
The NewViews Windows Service Installer is NewViews utility program run from the Windows start menu as Start>All Programs>NewViews 2.0>Windows Service Installer. It is used to install and start (or stop and uninstall) the NewViews server service. A prompt collects a few fields such as name and description of the service and the server database to use. You ordinarily use the default field values and only need to use different values when installing more than one NewViews service on the same computer.
By the NewViews Windows Service Installer.
You use the NewViews Windows Service installer to install the server. You normally do this only once. After that it should restart itself whenever you restart windows or upgrade NewViews.
Restarted whenever the computer or NewViews server is terminated.
The NewViews server restarts whenever the Windows is restarted, or whenever the server program itself is explicitly terminated using the task or server manager, or when NewViews crashes. The server computer may be a remote location so it may not be readily accessible, so this automatic restart can be very convenient.
Stopped and restarted when upgrading NewViews.
When a NewViews upgrade is installed, the install program temporarily uninstalls the server (service) and re-installs it after the upgrade completes.
The server database is a file than manages various server information such as the lists of accounting databases and their current connections. By default it is in the NewViews program folder on the server computer, and has the name server.nv2. Each time you create a new NewViews server using the NewViews Service Installer, a new server database will be created, although under most circumstance this will happen only once.
Yes. You can offer an accounting database under more than one database group.
Here is an example where you might want to do this. Suppose you manage many accounting databases on behalf of your customers and you want to accomplish the following:
Each of your customers should be able to remotely access one or more databases that belong only to them.
On the workstation login table, you want each customer to see only the databases belonging to them, and not databases belonging to other customers.
On the workstation login table, you want your staff members to be able to pick from a full list of the accounting databases.
The solution is to add a database group for each client and one database group for your staff. Add each application database under the appropriate client's database group, and also add it under a database group for your staff. When a client presses <F3> on the File field of a workstation row they will see only their own databases, and they will have their own database group password. When your staff presses <F3> on the File field they will see all databases, and one password protects that list, so your staff doesn't need to manage a large number of passwords. Keep in mind that the contents of accounting databases are individually protected by user passwords, and database group passwords only keep lists of databases private.
Note that this is one example of how your accounting databases could be organized under database groups, but there is potentially no limit to the various organizations possible.
Yes. But suppose you open the database using port XXX and then another user also attempts to open the same database under different database group which is in turn under different port YYY. That user might get an errors such as "Database already in use.". Also note that there is no reason to use more than one server or port number other than backward compatibility.
The Window Service Installer has a Server database path: field. When you install a NewViews service the server database specified in this field will be created if it is not found (after you are asked to confirm). By default the server database file is c:/nv/server.nv2 assuming the NewViews folder if c:/nv. There is actually no reason to change this value because you will typically use only one server.
Add a row to any workstation and enter the URL or IP of the server computer in the Server field, and the keyword "server" in the File field. Then double-click on the row to open windows on the server itself so you will see the offered databases and live connections. Note that the server should be protected by a password so the first time you open windows on the server a password may be collected.
If you are displaying the database group field on the workstation then it also must be set to database group SERVER. However, if not already specified, the database group will be set to SERVER automatically when the File field is server.
First note that if you have opened a window on a server to monitor and manage it, and then you shut that window, window closes, but the server is not affected, and keeps running. In fact, the server is rarely ever shut down. If you really want to shut it down you run the NewViews Windows Service Installer and click the "Uninstall" button. Note that any workstations that have the server or any of its accounting databases open will get "lost connection" messages.
Just download the NewViews upgrade and run it. If a NewViews server is running, the installation of the upgrade will temporarily shut down the server and restart it afterwards. This may cause "lost connection" messages on any workstations that have databases open through the server.
Yes.
There is one potential complication regarding installing upgrades. Typically you download a NewViews upgrade onto the server computer and upgrade the server. Then any workstation connecting to the server can automatically upgrade from that server. But this doesn't work when the workstation and server are both running on the same computer because they are both ultimately running the same executable. This is only a minor glitch because you can simply shut down the workstation before you upgrade the server. Then both workstation and server are simultaneously upgraded so you can just restart the workstation and connect it to the server. On variation is that if you are running the server and workstation out of separate NewViews installation folders (pretty advanced topic) then the complication described here doesn't apply and you can simply upgrade the workstation from the server.
Instead, use the NewViews Windows Service Installer to run the server. The server database is specified in the installer dialog so you can change it if necessary but is most likely the same database you have been using; i.e. c:/nv/server.nv2 where c:/nv is the NewViews folder. You don't have to run the server again because it is now running as a NewViews service. The real difference will be that a user interface didn't pop up on the server when you did this. Instead, you now add a row to your workstation login table and specify the server URL or IP and specify "server" in the File field. Double-click and you're back to the same old window interface on a server where you should see the same list of databases that the server was offering, and you can monitor the connections as they come and go. You should now issue the File>Set Server Password so that only you and selected personnel will be able to manage and monitor the server.
That feature is no longer necessary because accounting databases are upgraded on demand whenever they are opened, even when opened remotely from a workstation (more below).
Before services were introduced you would install an upgrade and then restart the server. The server would convert the server database and then ask if you wanted to convert all accounting databases that were offered by that server. Any accounting database that could be converted would then be converted. After the introduction of services this feature was no longer feasible due to way services are upgraded. Instead, accounting databases are now converted "on demand". After upgrading a server each accounting database is converted the first time it is opened and that is done even when being opened through the server from a remote workstation. This was not allowed before, and it was the underlying reason the ability to upgrade all accounting databases was introduced in the first place.
When more than one user is making changes to the same database, conflicts can arise. We call these conflicts collisions. Collisions can only occur under multi-user access, i.e. when more than one user is accessing the same database at the same time. Collisions rarely occur because of the underlying database technology and also due to the inherent organization of objects in an accounting database. You almost have to go out of your way to make collisions happen. A collision always occurs when two or more objects are being inserted, changed, or deleted by two different users and NewViews determines that such simultaneous changes could be logically inconsistent.
Yes. Any number of users can post transactions to the same account or journal at the same time. So, for example, you can have many users entering sales invoices and cash receipts on the same journal or that affect the same customer. Any user who happens to be viewing the journal or that customer's postings, i.e. account ledger, will see the changes appear as they happen. Or if you are reviewing a report that displays customer totals, such as an aged accounts receivable, you may see the amounts change as transactions affect the totals. None of these operations will cause a collision. The same is true for accounts of all types.
You have to be changing information on the journal or account itself. In the previous example, we said that many users were adding or changing transactions that post to the same customer, and this does not cause collisions. That is because the transactions are actually in collections belonging to the journal or customer account, but are not direct changes to the journal or account itself. But if you are in the middle of changing fields on the journal or customer account itself, such as the name or description, or tax or address information, and while doing this, another user tries to change the same journal's or account's fields, collision will occur.
Suppose user GREEN is changing fields on a customer account, say customer ACME. Note that GREEN is changing fields on the account itself, such as the name or description, tax rates, etc., and is not merely adding or posting transactions to ACME. Suppose another user, say SMITH, tries to add an invoice or cash receipt to ACME. This causes a collision and an error message appears on SMITH's screen. The error and the help on the error inform SMITH that a collision occurred because GREEN is currently changing ACME. SMITH is told what objects collided and which user is currently changing that object. SMITH can retry the changes but they will not succeed until GREEN is finished changing the account. When GREEN commits the changes by pressing <F5> or by simply moving off the ACME account, SMITH can then make changes that affect ACME. But until GREEN is finished making changes directly to the ACME account, no other users can post to ACME without generating a collision.
Usually none. At most, SMITH could only lose the information just typed into the field. When SMITH uses edit assist, i.e. the <F3> key, the collision is detected before any information is changed. So a collision error message would usually be displayed before SMITH could select ACME for a new transaction, or before SMITH could change any information on any existing transaction that posts to ACME.
No. You could say it serves the same purpose as record locking because NewViews collision detection does temporarily suspend other users from changing certain objects. But unlike record locking, NewViews collision detection is a dynamic algorithm that relies on logical relations in the object database organization. Records are never explicitly locked. If NewViews used record locking, then when GREEN was changing ACME, other users would only be locked out of ACME itself, not ACME's transactions, unless all transactions belonging to ACME were also explicitly locked. NewViews goes further to determine that changing other objects below ACME, such as transactions affecting ACME, also are logical collisions, and also temporarily suspends changes to them. But remember, nothing is actually locked. When GREEN finishes making changes to ACME, the transactions belonging to ACME can again be changed, not due to any unlocking, but simply because NewViews will not detect a collision any more.
Yes. By changing ACME and by NOT committing the changes, you can effectively prevent any transaction work on the ACME account. Note that any use of collision detection in this way is temporary in nature. When you move off the object it is committed and collision will no longer be detected. In the extreme, you will have to exit the database eventually and this act will automatically commit the changes. There is a better way to prevent changes to ACME on a more permanent basis. If you want no further changes made to ACME just set the ACME active field to inactive.
By changing any object and by not committing the changes you can effectively suspend changes to all other objects below in the database organization. Any user who tries to change an object below will be informed through a collision that the change is prohibited, why it is prohibited, and which user is responsible for prohibiting it.
Change the description of the sales invoice journal and don't commit the change. All changes to sales invoices, including adding new invoices, and changing or deleting existing invoices, will result in a collision. All work on sales invoices is effectively suspended. To release the journal and to set the description back to what it was, just issue the Edit>Quit command. Note that you must leave your window and the current position in that window parked on the journal because moving off the journal or moving to another window will commit the changes.
If you want to stop all changes to accounts receivable, including not just sales invoices but all transactions, such as cash receipts or adjustments, then change the AR account, say the description field. Because all customers are below AR you have just disabled changes to all customers. This suspends not only transaction activity on the customers, but also changes to the customer accounts themselves.
The real question here is just how far does collision detection go? The answer is that there is no limit to how widely, or narrowly, you can suspend activity. You can suspend all transaction activity by changing the root account, or the root journal. Take your pick. Or you can suspend activity just for the accounts on a particular report by changing a field on the report itself, such as its description. Until the changes are committed or quit, no account on that report can be changed. In the extreme case, you can suspend all database activity by changing the root object.
Probably. But if it is, then don't grant the power. Remember, a user can only access that portion of the database to which access has been explicitly granted. And that means that the user can only make changes to that portion of the database, and thus cause collisions only within a restricted area of the database.
For example, you might grant a user, say SMITH, access to a purchase invoice journal and nothing else. SMITH can only work on purchase invoices. SMITH can post to vendors, inventory, expenses, and whatever the purchase journal allows, but SMITH cannot position on these accounts, see their ledgers, or make changes to them in any other way. Because SMITH cannot access these accounts SMITH cannot suspend them. The actions of SMITH can only cause collisions on purchase invoices, and in all likelihood, SMITH will never experience a collision, unless it originates from above.
Good question. When a user logs in, a session object is added. If you are changing any object above the session, including the root object or the system object, then the attempt to add a session should result in a collision. However, NewViews bypasses collision detection in certain special system-related areas (these are system objects, after all), and the ability to log in or out is not suspended.
Yes. Collision detection works the same way at all levels. Suppose SMITH adds a sales invoice to a sales invoice journal. SMITH enters a date and selects customer account ACME but does not yet commit the invoice. GREEN happens to be on the same journal so GREEN sees the invoice appear and the fields change. If GREEN changes the date or any other field on the invoice, a collision occurs because SMITH has not committed. GREEN can even try to add an invoice line item but again, a collision will occur because the invoice header currently being changed by SMITH would collide with changes to any line item below it.
SMITH now commits the invoice header and starts adding line items. GREEN immediately starts adding line items as well. Collisions do not occur because there are no line items above or below each other. They are siblings. SMITH and GREEN are now working on the same invoice and each can see the changes being made by the other as they appear in real time.
However, if SMITH positions on a line item currently being changed by GREEN (or vice versa) and tries to change or delete it, a collision will occur. If SMITH goes back to the header and tries to change the date or customer, a collision is likely to occur. When SMITH does this, if GREEN is currently changing a line item, then SMITH will get the collision error and SMITH's change will be prohibited. But if GREEN is not currently changing an item, then SMITH's change will be allowed. If SMITH is still working on the header when GREEN tries to add, change or delete any line item on the invoice, then GREEN will get the collision error.