Dynamic-CD
Search : 
  Powered by FindinSite

ASP Documentation
Overview
• Introduction
• Getting started
• Dynamic-CD wizard
Passwords & Encryption
• Overview
• Example 1
• Example 2
Scripts
• The script language
• Script examples
• Database scripts
Technical details
• Applications
• Built-in objects
• Character Encoding
• Cookies
• Database CDs
• Development tips
• FAQs
• Future developments
• Global.asa
• Network support
• Object registration
• Resources
• ScriptingContext
• Server-side includes
• Sessions
• Technical limits
    
Frequently Asked Questions

Dynamic-CD under Windows Vista
Dynamic-CD now supports guest users running Windows Vista and Windows 7.

For Vista, Microsoft had increased the security on certain operations that Dynamic-CD needs to run correctly. Users MAY have to right-click on the program /dyncd/dyncd.exe on the CD and select "run as administrator".


Connecting to a database
If you are having trouble getting a database to work using Dynamic-CD, the most likely cause is a faulty connection string. For details about how to connect to your database, look here.


Starting Dynamic-CD
Dynamic-CD-Wizard generates the file "Autorun.inf" in the image directory. This file will make a CD autorun when inserted by a user.

Some CD drives do not support the autorun feature and some users may have switched off this facility. You will need say what to do in this case.

One possibility is to provide a batch file called something like "startTheCD.vbs" with contents

SET WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "dyncd\dyncd.exe"
This is a VBScript batch file that will start Dynamic-CD on Windows 98, 2000 and XP, but not on Windows NT.


How secure is the Dynamic-CD encryption algorithm?
Dynamic-CD encryption is a version of the Vernam Cipher, which "of all the methods of encryption ever devised, is the only one has been mathematically proven to be completely secure." Look here for further details.


Internet Explorer already supports VBscript - why do I need Dynamic-CD
You can include VBscripts in HTML pages and they will be processed by Internet Explorer. However, Netscape browsers will not process them. Dynamic-CD's script support also allows you to catch <FORM> and QueryString variables and store Session variables. Browser scripts are visible to the user and cannot be encrypted or password protected. Finally, most ASP code is written for server side processing. While such scripts are easy to transfer to Dynamic-CD, they are not directly transferrable to run browser-side.


What happens is I start more than one copy of Dynamic-CD?
Only one copy of Dynamic-CD can run at the same time on the same port. Starting a new copy will show a message alerting the user to the fact that Dynamic-CD is already running, and that they can show the HOME page by clicking on the CD icon in the tray at the bottom right of the screen.

You can, however, run another copy of Dynamic-CD on a different port.

If you reinsert an autoplay Dynamic-CD, the autoplay function is equivalent to starting a new copy of Dynamic-CD, which will alert the user as mentioned above.


How can I find out if Dynamic-CD is running?
Use the  Request.ServerVariables  parameter "DYNCD_HOST" to determine if Dynamic-CD is running. This can be useful if you use the same script code both on a server and on a Dynamic-CD - use DYNCD_HOST to distinguish the two cases.


Server-side JavaScript / JScript
Dynamic-CD does not support mixed server-side script languages such as generated by older versions of Adobe GoLive. Dynamic-CD's script support is limited to VBScript. Client-side JScript is not supported. Browser-side JavaScript is not affected by Dynamic-CD.


Serving large files
Unless a large file needs to be password protected, it is best to pass the file directly to the browser rather than having it served by Dynamic-CD. Look here for further information.


Serving files that need special processing
Files with extensions such as  *.doc, *.xls, *.bat  often receive special processing by the browser. The only file extension recognised by Dynamic-CD is *.asp. To ensure special processing by your browser, try sending the files directly - by-passing Dynamic-CD - as follows :
<%
  rootDir = Request.ServerVariables( "ROOT_DIR_FILE_URL")
%>
<A HREF="<%=rootDir%>\test.bat">run batch file</A>

Note - the latest edition of Internet Explorer for Windows XP considers a request from a http URL to a file URL to be a security risk and does not support the above.


Problems with database access
If you have installed database support files (MDAC) but are having problems with database access, it may be because you have a multi-boot machine. Loading different versions of the ADODB support files (MDAC) onto different boots can cause problems.

It is important to check for the presence of the ADODB object in the main body of a script before proceeding - otherwise error checking may be by-passed. Look here for details.


Checking whether FileSystem, ADODB and other obects are installed
It is important to check for the presence of the required objects in the main body of a script before proceeding - otherwise error checking may be by-passed. Look here for details.


How do I register my own objects?
The Dynamic-CD - specific Server.RegisterObject method allows you to register your own objects straight from the CD. Look here for further details.


Problems with the FileSystemObject, Windows 95 and Windows NT4.0
Neither vanilla Windows 95 nor Windows NT4.0 seem to support the  Scripting.FileSystemObject .
Check all platforms before assuming that a given object is supported. Look here for details.


What about firewalls?
If your computer is behind a firewall, you may have to disable proxying of address 127.0.0.1 for Dynamic-CD to work. Consult your browser's documentation to find out how to do this.

In Internet Explorer, select the menu Tools+Internet Options+Security+Local Intranet+Sites+Advanced, then add 127.0.0.1

In Internet Explorer, you should also check the menu Tools+Internet Options+Connections+LAN Settings. If you have "Use automatic config script" selected, deselect this.


Encrypting databases ; setting database passwords
Do not encrypt or password protect a database using Dynamic-CD-Wizard - if you do, the ADODB component will not be able to read it. Instead, password protect the database using Microsoft ACCESS® and include the password in the connection string :
<%
  Con.Open "Provider=Microsoft.Jet.OLEDB.4.0" &_
    ";Data Source=" & dbPath &_
    ";Jet OLEDB:Database Password=" & dbPwd
%>


What happens when I navigate to a directory
Dynamic-CD does not support displaying a directory listing. If you navigate to a directory, Dynamic-CD will first try to find one of the following files (in this order)
  • index.htm
  • index.html
  • index.asp
  • default.htm
  • default.html
  • default.asp
    and navigate to the first file found. If one of these files is not found in the directory in question, Dynamic-CD will show a 404 error page.

    If you need to show a directory listing, use the FileSystemObject.


    Testing Dynamic-CD on Windows 95
    If you are testing Dynamic-CD on Windows 95, Internet Explorer 4 must first be installed so that the VBscript engine is registered on the machine. Before running Dynamic-CD, make sure that you are able to connect to the Internet with Internet Explorer - remember that in Windows 95 you have to set up TCP/IP transport manually by using Control Panel / Network. Select the Microsoft Dial-Up Adapter.


    Using wild cards and LIKE in SQL commands
    ADO for ACCESS seems to consider '%' to be a wild card. This means that
    MySQL = "SELECT * FROM [parts] WHERE [description] LIKE '*xyz*'"
    should be replaced with
    MySQL = "SELECT * FROM [parts] WHERE [description] LIKE '%xyz%'"

    Alternatively, to do wild card searches on Recordsets, use the filter Recordset property :

    <%
      thisSQL = "SELECT * FROM [" + thisTable + "]
      SET RS = Con.Execute( thisSQL)
      RS.filter = "[" + thisField + "] LIKE '*xyz*'"
    %>


    Using ON ERROR RESUME NEXT
    An ON ERROR RESUME NEXT statement becomes inactive when another procedure is called, so you should execute an ON ERROR RESUME NEXT statement in each called routine if you want inline error handling within that routine. When a procedure is exited, the error-handling capability reverts to whatever error-handling was in place before entering the exited procedure.

    For example, try the following with and without the commented line in  testSub  :

    <%
      ON ERROR RESUME NEXT
      testSub
      response.write "<BR>Back from testSub"
      errChk
    
    ' --------
    SUB testSub
    ' try removing the comment on the next line
    '  ON ERROR RESUME NEXT
      Request.Cookies( "fred") = "fredval"
      errChk
    END SUB
    
    ' ------------
    FUNCTION errChk
      IF Err <> 0 THEN
        Response.Write "<BR>Error : " + Err.Description
        Response.Write " (" + Err.Source + ")"
      END IF
      Err.Clear
    END FUNCTION
    %>


    © Copyright 2000-2010 PHD Computer Consultants Ltd