Server
Because the server has to process most of the data, this computer
should be as fast as possible with as much RAM and hard disk space
as possible. Is should also have the fastest possible network connections.
A 100 megabit LAN (or faster) is recommended.
Server Hardware
· Computer/Processor: Pentium 3 800MHz or comparable compatible
CPU. Recommended is Pentium 4 2.8GHz or the latest available.
· Memory: 512 megabytes (MB) of RAM. Recommended is 1 gigabyte
(GB).
· Hard disk: IDE, 2MB cache, 7200 rpm, ATA100. A mirrored Raid
system is recommended.
· Network card: 10/100 megabit.
Server Software
· Windows 2000 based operating system (e.g. 2000, XP, Server
2000, Server 2003) with the latest service packs installed.
· SQL Server 2000 or MSDE 2000.
· Microsoft Data Access Components (MDAC). Latest version.
Client
Because of the nature of the client-server database, clients do not
need to be high specification machines. That said, they do need to
be able to run the operating system quite happily and be able to run
background tasks with a handful of applications at the same time.
Any PC bought today is more than capable of doing this.
The most important hardware for the client is the network card (or
the interface with the server. i.e. broadband, dial-up, etc). The
faster this is, the faster the client application will run.
Client Hardware
· Computer/Processor: Pentium 3 400MHz or comparable compatible
CPU. Recommended is Pentium 4.
· Memory: 256 megabytes (MB) of RAM. Recommended is 512 megabytes
(MB).
· Hard disk: N/A. Any modern hard drive with enough space for
the operating system and temporary file processing will be sufficient.
· Network card: 10/100 megabit.
Client Software
· Windows based operating system (e.g. 98, ME, 2000, XP, Server
2000, Server 2003) with the latest service packs installed.
· Microsoft Data Access Components (MDAC). Latest version.
· Reporting in Back Office requires Crystal Reports 9 runtime
|
  |
2. What are the enhanced features of Back
Office?
In no particular order:
· Enhanced security and database robustness.
· Remote database connectivity (TCP/IP).
· DPOS transaction log importing. This gives more reporting
possibilities.
· Centralised exception log (stored in database).
· Centralised POS Job log (stored in database).
· MDI document interface (i.e. multiple browser windows) and
a fresh new look.
· Editable and customisable (user specific) browsers. Any field
displayed in the browser can be used to order the list of records.
· Copy functions in all browsers. This copies the selected
record in a browser to a new record.
· Enhanced edit screens. Each edit screen now has navigation
capabilities within them to easily move between records. The user
can also add new and delete records from with the edit screen without
having to drop back to the browser.
· Sub Departments.
· POS jobs are scheduled with Windows Scheduler, so no need
for any programs to be running all the time.
· Automatic program updates. Program files are stored in the
database. When a user logs on the program checks for newer versions
of files in the database and updates accordingly. This ensures all
users are using the correct version of the program for the database.
· Enhanced report linking. Multiple reports can now be linked
to 1 report type (e.g. Sales Report). At the time of taking the report
(or refreshing) the user can choose the report file to use. The system
remembers the user’s last report used as well. Reports are also
stored in the database. This works in the same way as the program
updates and ensures that users are always running the correct version
of the report.
· Enhanced report settings. Report settings can now be changed
in the report window without having to close the report and start
again. All reports, where logical, have multiple selection capabilities
(i.e. selected locations and groups in sales reports).
· New reports: Cashiers financial report and hourly sales report.
· Transaction Server tray application. This program sits in
the background checking for transaction log files in a selected folder
(usually C:\tillserver). Files are imported directly into the database
giving an online real-time system.
· Enhanced PLU Updates section. PLUs are now flagged with an
update type (i.e. price change, minor change, full change). Type of
update can now be selected in the POS Job (i.e. only export price
changes).
· Exception processing of transaction logs. When importing
transaction logs, if the system cannot import the line (i.e. unknown
record type or invalid field value) then it is stored in an exceptions
file in the database. These exceptions can then be processed later.
· Alphanumeric PLU codes can now be used.
· Real-time sales screen. Configure 10 views of 4 panels to
display sales data as it happens. 4 screens can be opened at once
to give a total of 16 different sales windows. Choose to group data
by POS Location, POS Terminal or Cashier. Display data as financials
or hourly sales. Please note that Transaction Server needs to be configured
and running for this to work
|
|
3. What needs to be done to Datasym.POS
to get it to work with back office?
Change the back office type in the initialisation file to Back Office:
BACKOFFICETYPE D
If using the transaction server program to monitor
the tillserver folder for transaction logs, then set the following
in the tillpara.ini file:
REALTIMEEXPORT True
This ensures that DPOS will export transactions
as they happen.
4. Where is the data held on the server?
If using the default installation of SQL Server or MSDE, the data
files are located in C:\Program Files\Microsoft SQL Server\MSSQL\Data
The default database installed by the back office server installation
wizard is called DPOSBOS; therefore the files used are:
· DPOSBOS_Data.MDF and
· DPOSBOS_Log.LDF
The MDF file contains the actual data. In general
this file will never decrease in size.
The LDF file contains the log of actions (“transactions”
in database speak) performed on the database. This file is dynamic
and will grow and shrink (dependent on a setting within the database)
as the database is used and consequently backed up.
Both files are required for a working database and they cannot be
mixed with another database of the same name.
How do I back up my data?
Use the Tools - Backup Database routine.
Please note that the user must have rights to perform the backup.
This can be set in the users section.
Alternatively you can back up the database by backing
up the MDF and LDF files manually.
When SQL Server is running these files cannot be copied, moved, renamed
or deleted; therefore the server needs to be stopped before these
files can be backed up.
NOTE. Some professional backup programs can back up SQL Server databases
without the server having to be stopped.
To stop/start the server:
• Open the SQL Server Service Manager – This is usually
located in the tray of the server.
• In the services drop down box, select SQL Server – Make
sure the Server is correctly set.
• Press the Stop button – The server is stopped when the
green triangle changes to a red square.
• Press the Start button – The server is started when
the red square changes to a green triangle.
While the server is stopped, the data files can
be copied etc.
5. Is there an ‘Add Next’ function
as in Stockade?
Yes.
Open the PLUs browser (Maintenance – PLUs). Select the PLU to
copy and press the copy icon (or shift+F2). Enter a new PLU and description
and press OK add a new PLU record.
Is there a ‘Price Change Templates’
function as in Stockade?
Yes and is available in version 1.5. It has been renamed to PLU Change
Templates and is more flexible and powerful than in Stockade.
Can I configure Transaction Server to not display
the setup screen when it loads?
Yes. In the shortcut to transaction server put /s after the filename.
i.e. “C:\Program Files\Datasym POS Back Office\DPOSTS.EXE”
/s
This is useful when putting Transaction Server in
the startup group.
6. I’ve run the Upgrade installation
to update Back Office from an earlier version, but now I get a ‘database
does not match application version’ when I try to run the program.
What is wrong?
The local files have been updated to the latest version, but the database
needs to be upgraded also. This is a separate process from the installation
and needs to be performed by a system administrator.
To upgrade the database:
Open explorer and navigate to the installation folder (C:\Program
Files\Datasym POS Back Office by default).
Run the DPOSDBU.EXE program located in the folder.
Log in with system administrator password.
Close the program when all steps have been performed.
The database should now be at the correct version.
Any other clients logging in now will automatically be updated with
the latest files. This negates the need to install the upgrade on
every client PC.
7. Can I schedule a POS Job to run overnight
with only a dial-up internet connection?
Yes.
However, when running a POS Job it will not automatically initiate
the dial-up connection; therefore a batch script is needed to perform
the connect and disconnect procedures.
i.e.
POSJOB.BAT
rasdial <dial-up connection name> <user
name> <password>
"C:\Program Files\Datasym POS Back Office\DPOSJOB" "<POS
JOB name>"
rasdial <dial-up connection name> /DISCONNECT
The batch file can be scheduled to run in Windows
scheduled tasks as normal.
8. How do I setup my products (PLUs) to
sell in different locations?
By default all locations are created with Default Price Group set
to 1. This means that unless this value is changed all PLUs will be
either sold (or not sold) in every location and have the same price.
Therefore to set a location to be different from the norm you need
to change the Default Price Group for that location.
To do this:
• Log in to Back Office
• Go to Maintenance – POS Locations.
• Edit (or Add) the location in question
• Set the Default Price Group for that location to something
other than 1. i.e. 2.
Please note this does not change existing items
price group; therefore any items setup when the location was still
at Price Group 1 will still be 1 until this is changed.
New items created will have the Price Group for that location set
to 2 (or whatever the location is set to).
|
|
9. What are and how do Price Groups work?
Price groups are set to replace the Stockade feature which allows
you to make changes to an item’s price and sold at location
flag and this in turns changes the details in multiple locations (the
Locations to change box in Item Maintenance – Cash Register
screen).
Instead of selecting the locations to change you set up the PLU to
have a Price Group number in a specific location. The default price
group for a location can be set in Maintenance – POS Locations.
When you change the price of a PLU in a location with, say, price
group 1; the system will change the price in all other locations which
also have price group 1 set to the same price.
For example, suppose:
Location 1 is set to price group 1
Location 2 is set to price group 2
Location 3 is set to price group 1
Location 4 is set to price group 2
When editing PLU 1 you change the price in Location
1 to £1.50; Location 3’s price will also be changed to
£1.50.
If you also change the ‘Sold at Location’ flag in Location
2 to False; Location 4’s ‘Sold at Location’ flag
will also be changed to False.
This system allows the user to setup complicated
pricing structures across many locations, but once setup the maintenance
becomes quite easy. Especially when using the Price Grid page in the
Edit PLU screen.
|
|
10. I have more than 1 POS Location (separate
branch numbers) within the same site. How do I set up Back Office
and DPOS so that I have separate PLU files (buttons etc) in each branch,
but I can monitor the ‘Real-time’ sales for all locations?
In this instance you want the files being exported from Back Office
to go into separate folders for each branch, but the files being exported
from all DPOS terminals to go into a single folder.
E.g.
Suppose we have 1 server computer, 2 branches (within the site) and
4 POS terminals (2 for each branch).
Server is named Server1.
Terminal 1 is named B1T1 (which stands for branch 1 terminal 1. It’s
important to keep the computer name of terminals and the server short
as DPOS can only address UNC file names of 32 characters or less).
Terminal 2 is named B1T2.
Terminal 3 is named B2T1.
Terminal 4 is named B2T2.
B1T1 is the master till for branch 1 and B2T1 is
the master till for branch 2.
On the server computer we create a folder called
Sales and create a network share on this folder (also called Sales)
with read and write access rights. This folder will be used by the
terminals to place their exported sales files into.
On B1T1 (and on B2T1) we create a network share
on the C:\TillServer folder and call it TillServer. This will be used
by back Office to place PLU files into for each branch.
In Back Office we create the 2 POS Locations with
the following settings:
Code = 01
Description = Location 1
Branch Number = 1
Default Price Group = 1
Active = True
Import Folder = C:\Sales
Export Folder = \\B1T1\TillServer\
and
Code = 02
Description = Location 2
Branch Number = 2
Default Price Group = 2
Active = True
Import Folder = C:\Sales
Export Folder = \\B2T1\TillServer\
In Transaction Server (DPOSTS.EXE) we set the POS
Log Monitor Folder to be C:\Sales
For each terminal we set up DPOS with the following
settings in TillPara.ini:
LOCATION01 \\Server1\Sales\
For real time sales settings see ‘What needs
to be done to Datasym.POS to get it to work with back office?’
All other settings are as normal for this type of system. See the
DPOS set up manuals for more information.
‘Real-time’ sales screen is not working.
What is wrong?
There are a few settings that need to be in place and working before
the real-time sales screen displays correctly. It’s usually
best to take it from the beginning and work up to the full setup.
1. DPOS needs to be set so that it exports its sales
files as they happen.
To do this:
Edit the TillPara.ini file and make sure the following appears somewhere
within the file
REALTIMEEXPORT True
Please note the number of spaces between the words
is important and it is case sensitive.
2. Check that transaction files are being created
as they happen.
· Exit Transaction Server if it is running.
· Open the TillServer folder in explorer and delete any files
that match TS*.POS (i.e. TS000101.POS).
· Make a normal sale on the till and cash it off. Check the
TillServer folder for a newly created TS*.POS file (i.e. TS000101.POS
for branch 1 till 1).
If the file has not been created then check the
settings again. Make sure the right version of DPOS is running and
that the TillServer folder is set correctly.
3. Start up Transaction Server.
· The transaction server program is called DPOSTS.EXE and gets
placed in the installation directory when installing Back Office.
· Navigate to the installation directory in explorer (usually
C:\Program Files\Datasym POS Back Office) and double click DPOSTS.EXE.
The settings screen should be displayed.
· Make sure the Server Name, Database Name, User Name and Password
are set correctly by clicking the Test Connection button. If the connection
fails you will need to diagnose the problem (i.e. Is the Server Name
correct? Is the Server running? Is the LAN, WAN or Internet connection
working? Is the Database Name correct? Is the User Name correct? And
Is the Password correct?)
· Make sure the POS Log Monitor Folder is set correctly. Use
the folder icon on the right to browse to the correct folder. This
folder should be the same as that where DPOS is placing its TS*.POS
files.
· Make sure the Transaction Log Files Backup Folder is set
correctly. Again use the folder icon to browser to the correct folder.
Please note earlier versions (1.0, 1.1 and 1.2) do not create a Backups
folder off of the installation folder when installing; therefore this
needs to be created manually; this has been rectified in the v.1.3
install.
· Press Close and not Exit to begin monitoring for transaction
log files.
Please note Transaction Server always needs to be
running for the Real-time sales screen to work correctly; therefore
it is wise to place a shortcut to this file in the Startup program
group with the /s command line parameter. When Transaction Server
is running a blue circle icon is placed in Windows System Tray (bottom
right hand of the screen).
· Navigate to the TillServer folder again.
If all is well with Transaction Server the TS*.POS file created in
step 2 should no longer be in this folder (it has been moved out to
the backups folder for processing). If the file does still exist then
wait for at least the Polling Frequency time. If after this time the
file still exists then check all the Transaction Server settings again.
At this point, providing you don’t have a
very slow connection to the database, the sale that you put through
in step 2 should now be in the Back Office database, where it can
be reported on.
4. Start up the Back Office client program.
· The icon for this gets placed on the desktop during installation,
so double click this to open and log in to the same database which
Transaction Server is setup to use.
5. Check the POS Job Log to make sure the sale has
been imported correctly.
· Open the POS Jobs Log Browser by clicking the icon or selecting
Procedures – POS Jobs Log…
· The browser displays a list of all POS Jobs (including Transaction
Server imports) that have occurred since the system was started.
· Locate the Transaction Server entry for today. There are
several ways to do this, but I find the easiest way is to sort the
list by Date Time (ascending or descending. It doesn’t really
matter) and going to either the last (or first is sorting is descended)
record in the list. The Transaction Server entry for today will be
the last or very near the bottom.
· Select View Log Details… to ‘drill down’
to the individual log records for this job.
· Go to the Details page. You should see something like the
following:
28/07/2004 11:43:59. Processing TS000101.POS...
Renaming and moving TS000101.POS to backup folder...
File renamed to TS000101.364.040728.114359.pos
Storing POS file in database...
File stored successfully
Processing POS file...
POS file processed successfully
Putting temporary data to database and compiling sales data...
Database updated successfully (1)
· The ‘Database updated successfully’ line indicates
that the transactions tables in the Back Office database have been
updated with new data.
· The log details screen and the POS Jobs Log Browser can now
be closed.
6. Open the Real-Time Sales Screen.
· Open the Real-Time Sales screen by either clicking the icon
or selecting Procedures – Real-Time Sales. Please note the user
name you logged on with must have access rights to the Real-Time sales
screen.
· By default the sales panels are not active and do not display
any data; therefore click the Setup Panel 1 icon in the top right
of the top left panel.
· Tick the Active check box, select the POS Location that has
the same branch number as the till, leave the type as POS Location
and set the Display to Financials.
· Press Close and the panel, after a short pause, should be
activated and refreshed with data from the transaction tables. If
all is well then the sales amount should show up in the financial
totals.
Transaction Server does not update automatically.
What is wrong?
The most common reason for Transaction Server no updating automatically
is that it is running when the update is attempted. Windows operating
system does not allow a program file to be overwritten while it is
in use.
To get over this problem, exit the transaction server before logging
on with the client.
11. How do I import PLUs from DPOS into
Back Office?
The first step is to export the PLUs from DPOS:
1. In DPOS go into POS Data Maintenance – System Utilities
2. Select Export PLU File to Back Office.
3. Keep the default path and set the filename to be PLUS.DAT (i.e.
C:\TILLSERVER\PLUS.DAT)
4. Select OK to create the exported file.
The second step is to create a POS Job in Back Office
and run it:
1. In Back Office select POS Jobs
2. Select Add POS Job.
3. Add a description (e.g. Import PLUs)
4. Press the Select Locations button to select the location which
uses the TillServer folder in step 1 point 3 above.
5. Select the location by double clicking it in the browser and press
OK. The selected location should appear next to the Select Locations
button in the Edit POS Job screen.
6. Click the Import PLUs check box to select the action and make sure
no other check boxes are ticked.
7. Press the close button to save the Job and return to the POS Jobs
Browser.
8. Make sure the newly created job is highlighted in the browser then
select Run from the tool bar.
If the file has been created in the right place
and is in the correct format the PLUs should be imported. You can
check this by viewing the POS Job Log for this Job.
12. Can Back Office Server be installed
on Windows 9x operating system?
Yes and no. Although MSDE2000 can be installed on 9x, Datasym do not
recommend it.
There are certain security functions that are not available in 9x
which affect the system.
The first affect users will notice is that the Server
Components installation fails near to the end of the install process.
This is because the install is not able to use integrated security
to log in to the server and ‘attach’ the Back Office database
to the server. See the ‘How do I manually attach a database
to the server?’ question below on how to do this.
The database must be attached manually on 9x before the system can
be used. The install places the files in the correct folder on the
server, but does not attach them.
Because the integrated security function does not
work on 9x systems, there is no work around if the ‘SA’
password is lost. In this case you will need to uninstall and reinstall
MSDE2000.
13. How do I manually attach a database
to the server?
You may want to do this for several reasons:
1. Installing on a 9x machine.
2. Moving a database from one machine to another.
3. Installing an additional database.
To attach the database (This assumes the database
has been copied to the correct folder first):
· Open explorer and navigate to the installation folder (“C:\Program
Files\Datasym POS Back Office” by default).
· Run VTABLES.EXE program
· Log in to the master database using the SA account (or integrated
security if on the same machine as the database).
Server Name: <SERVER NAME>
Database Name: Master
User Name: SA
Password: <PASSWORD>
· Go to the query page.
· Type the following in the query box (the upper box) and press
the green button (or Ctrl+E) to execute the query:
EXEC sp_attach_db @dbname = N'DPOSBOS',
@filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\DPOSBOS_Data.MDF',
@filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\DPOSBOS_Log.LDF'
· Close VTABLES.
|
|
14. How do I license Back Office?
Back Office needs to be licensed before it will work. Licensing works
by installing a license file into the Back Office database.
Datasym provide a 30 day trial license file on the installation CD
which can be used free of charge.
To install a license file:
· Start the Back Office client program
· Go to Help – License
· Log in with an administrator password
· Press the Load License File button and select the license
file that has either been sent to you by Datasym or the trial license
on the CD.
· Check the information on the screen is correct
· Finally press the Install License File button
The final step installs the license into the database.
You should now be able to log in normally.
I can’t select multiple records in the PLUs
browser. What is wrong?
Load All Records has been turned off.
To turn Load All Records on and off:
· In the browser window select Utilities – Customise…
The customize window appears on the right hand side of the browser
· Select Advanced… The Advanced Grid Options window is
displayed.
· Check or uncheck the Load All Records box on the Database
page.
Note this setting is particular to the browser you
are viewing.
15. I’ve forgotten the SA password.
Is there any way of recovering this?
Yes, but this should be a last resort.
· Go to the server computer which the database
is installed on and log in with an administrator user.
· Open explorer and navigate to the installation folder (“C:\Program
Files\Datasym POS Back Office” by default).
· Run the VTABLES.EXE program
· Log in to the master database using the integrated security
option.
Server Name: <SERVER NAME>
Database Name: Master
User Name:
Password:
Tick the NT Integrated Security check box.
· Go to the query page.
· Type the following (replace <password> with the desired
password) in the query box (the upper box) and press the green button
(or Ctrl+E) to execute the query:
EXEC sp_password null, '<password>', 'SA'
· Close VTABLES.
16. I’ve installed Windows XP SP2
on my Back Office server and now I cannot connect to the database
from my clients. What is wrong?
By default SP2 turns on the Windows software firewall. This blocks
any unauthorised inbound TCP/IP communications.
SQL communications are therefore blocked and need to be authorised.
· Go to: Start – Control Panel –
Security Center
· Click Manage security settings for Windows Firewall
· Go to the Exceptions tab
· Click Add Port…
· Enter the following settings and press OK:
Name: SQL
Port Number: 1433
TCP or UDP: TCP
Clients should now be able to connect as before
SP2 was installed.
|
|
17. I want to connect to my Back Office
server over a standard broadband connection. What is the best and
most secure way of doing this?
The most secure way of connecting to a server is via a Virtual Private
Network (VPN). This is a vast subject and as such, the setting up
of a VPN will not be covered here. This will be covered in a separate
document.
When you have a VPN connection established, you should be able to
use the computer name of the server in the Server Name field of the
log in screen (i.e. as if you were on a local LAN/WAN with the server).
If you do not have a VPN connection over the internet then the client
program can connect directly with the server using an SQL TCP/IP connection.
This is all handled by Microsoft’s MDAC software, so the most
recent version of this should always be installed at the client and
at the server.
When using a SQL connection, you should use the IP address of the
server in the Server Name field of the log in screen (i.e. 137.168.1.1).
Whether or not you use a VPN or an SQL connection the most important
aspect when connecting to a server over the internet is for the server
to have a fixed IP address. This is set by the broadband provider,
so they should be consulted for setting this up.
Without a fixed IP address the IP address of the server will change
from time to time (the exact timing is set by the broadband provider)
and so a client might be able to connect one day, but not the next.
The problem with a fixed IP address is that it is a beacon to hackers
and viruses. If the same server can be found at the same IP address
for a long period of time it is easier for a hacker to systematically
attack it until they gain entry.
Another problem is that many hackers know that SQL communications
default to TCP port number 1433, so they use a “robot”
program to crawl through IP addresses until a SQL Server is found.
Once found the hacker can then attempt to gain access to the server
by using “brute force” (attempting all combinations of
letters and numbers until the password is found).
The easiest way of securing the server against hackers, SQL hackers
and viruses is to install a hardware router/firewall between the server
and the broadband connection. Please note that a specialised router/firewall
needs to be put in place if using VPNs to connect to the server. Datasym
have researched the available units on the market and can provide
and set-up units that are guaranteed to work with Back Office (and
VPNs if necessary).
Once a router is in place there is still some setting up that needs
to be done on both the router and the server to make it as secure
as possible.
One requirement of the router is the ability to perform “port
mapping” or “port forwarding” (different routers
use different terms). This basically passes TCP packets from the router
to a defined computer behind the firewall.
In the most basic scenario you would pass TCP Port number 1433 through
to the server computer. Please note this basic scenario stops hackers
and viruses, but does not stop SQL hackers.
To be totally sure you have done everything possible to stop all forms
of attack, the default port number of SQL should be changed from 1433
to another number. Datasym recommend using anything from 5000 –
6000 as a possible port number.
If your router supports mapping and transforming of packets then the
easiest and most elegant way to change the port number is on the router’s
port mapping table.
For example you would set up the router to pass TCP Port number 5000
through to the server as port number 1433. Port number 1433 is not
ported through at all. Therefore a SQL hacker would attempt to locate
a server on port 1433, but because the router is not forwarding 1433
anywhere then to the hacker it appears as if there is no SQL server.
However if anyone attempts to find the server on port 5000 they would
“see” the server as normal. Most, if not all, SQL hackers
do not use any other port number than the default when searching for
servers. It would simply be too time consuming to crawl through even
one IP address.
If your router does not support transforming of packets, then the
changes to the port number must be made directly on the server. This
setting will affect anyone wanting to connect to the server, not just
those connecting over the internet.
To change this:
· In explorer navigate to: C:\Program Files\Microsoft SQL Server\80\Tools\Binn
· Run the svrnetcn.exe program located in this folder.
· Select TCP/IP protocol in the enabled protocols box and press
properties
· Change the Default port number (The optional Hide server
box can be ticked as well. This stops the server from broadcasting
itself on the LAN/WAN. The server never broadcasts itself on the internet,
therefore is not used by SQL hackers).
· Click OK and shut the program down. The server will need
resetting before the changes take affect.
Once the changes are made to the router (and the
server if necessary) the clients need to specify which port number
to use when logging on. This is achieved by putting the port number
after the server’s IP address in the Log In screen separated
by a comma. I.e. 137.168.1.1,5000 (or ServerA,5000 if on the local
LAN and the server’s default port number needed changing too).
Please note if using a VPN connection then the port mapping and transforming
is not necessary as the server simply appears as a computer on the
LAN/WAN. All security is handled by the setting up of the VPN in the
first place and there is also no need to forward port numbers etc.
In addition to the security of the server over the
internet, the speed of the broadband connection should be thought
out to provide the best solution. Most broadband is provided by ADSL
connections. ADSL stands for Asymmetric Digital Subscriber Line and
the asymmetric part basically means that the speed of downloading
data is faster (up to 5 times) than the uploading of data. This is
fine for standard internet activities such as web browsing and email,
but a SQL Server will more likely than not be outputting just as much,
if not more data than it receives; therefore it would make sense that
the connection speed be the same in both directions. SDSL (or Symmetric
Digital Subscriber Line) does just this. SDSL can be expensive, so
it may be more economical to install 2 (or more) ADSL lines at the
server site. These can double up as needed to provide greater bandwidth
for both downloading and uploading of data. This becomes more important
as more connections (or sites) are added to the server.
