I try to create a InterBase database on Delphi using TIBDatabase type.
ibdb:=TIBDatabase.Create(nil);
with ibdb do
begin
SQLDialect:=3;
DatabaseName:=Self.name;
Params.Clear;
Params.Add('USER "SYSDBA"');
Params.Add('PASSWORD "masterkey"');
Params.Add('PAGE_SIZE 4096');
LoginPrompt:=false;
try
CreateDatabase;
except on E: Exception do
ShowMessage('Can''t create database. '+E.Message);
end;
end;
Self.name is string like a 'localhost:C:\db.ib'.
Code works without errors. Database file created. But IBConsole doesn't show this database on IB server. How can I check that database was added on server?
The following works for me and avoids all the problems you've mentioned so far:
1 Start a new Delphi project
2 Drop a TIBDatabase onto the form
3 Add the following CreateDatabase procedure to the form
procedure TForm1.CreateDatabase;
begin
IBDatabase1.SQLDialect:=3;
IBDatabase1.DatabaseName := 'D:\aaad7\interbase\newdb.gdb'; //edit for
// your system & check that you have file-creation rights in the
// database folder you want to use.
IBDatabase1.Params.Clear;
IBDatabase1.Params.Add('USER ''SYSDBA'''); // Note that this line
// contains 5 single-quotes and no double quotes
// Also note that the omission of the usual '=' between the
// parameter name and value for the USER and PASSWORD is deliberate,
// because it's evidently required by the IB api
IBDatabase1.Params.Add('PASSWORD ''masterkey'''); // Ditto
IBDatabase1.LoginPrompt:=false;
try
IBDatabase1.CreateDatabase;
except on E: Exception do
ShowMessage('Can''t create database. '+E.Message);
end;
end;
4 Add a TButton and set its OnClick event to call CreateDatabase.
5 Compile & run and click Button1.
Using Delphi 7 and Interbase XE7, this code successfully creates the newdb.gdb database and this database stays on disk after the Delphi application terminates. I can then open the database in IBConsole using the procedure described below. I cannot delete the databse file via the windows shell while IBConsole is running but I can after I close it.
Do you get the same result and, if you do, does that solve your problem and if not, why not?
Btw, I've written the CreateDatabase code to avoid the use of "with", because it usually creates more problems than it avoids and I loathe it, and
to avoid the dynamic creation of the TIBDatabase component, because that serves no useful purpose.
Notes
Once you have created a database in code as above, there is no need to "attach" it to IBConsole.Exe or to the Interbase server in order to be able to use it.
You could set up an IBDatabase, IBTransaction and IBQuery to connect to it, and create tables in it by issuing "CREATE TABLE ..." SQL statements to it from the IBQuery.
If you want the database to be listed in the IBConsole utility, you can either
a) Add it manually using the procedure in Previous Answer below or
b) Add it in code to the IBConsole configuration file, IBConsole.XML, which you will find in C:\users[your user name]\Appdata\Roaming\Embarcadero\Interbase, using a Delphi XML access library of your choice. If you add it using the manual procedure below, then close IBConsole.Exe so that the config file is updated on disk, you'll be able to examine the XML file and find the node for the database under the Server/Databases node. It will look something like
<key name="Newdb">
<value name="Accessed">A32BFE2475B3E440</value>
<value name="CaseSensitiveRole">0</value>
<value name="CharacterSet"/>
<value name="Created">7DB1327474B3E440</value>
<value name="DatabaseFiles">D:\aaad7\Interbase\NEWDB.GDB</value>
<value name="Encrypted">0</value>
<value name="EUA Enabled">0</value>
<value name="Password">096e6376786a78726d82</value>
<value name="Role"/>
<value name="Save DBAlias">1</value>
<value name="SEP"/>
<value name="Use DBAlias">0</value>
<value name="Username">SYSDBA</value>
<value name="UseSSL">0</value>
</key>
Previous answer
Try this:
In IBConsole, click the Local Server node and select its Databases node
Right-click the Databases node and select Add
In the Add database and Connect pop-up, click the button to the RHS of the File: field
From there, you should be able to navigate to and select your new database.
Tested with Interbase XE7 IBConsole.
If that doesn't work for you, exactly which step fails and how?
It seems I find the answer. Code creates database file and add database on InterBase server. It can be checked by isql utility. Strange that IBConsole and IBExpert don't show all databases on server in current moment but only created by the same tool as I understand.
Related
it's possible to define an alias for a stored procedure (sql-native)?
In the documentation, reference is made only to: SEQUENCE and TABLES
1) CREATE PROCEDURE OWXXCOLL.STORED1()
2) CREATE ALIAS DB2C.STORED1 FOR OWXXCOLL.STORED1;
3) CALL DB2C.STORED1();
EDIT 2021-05-14
The original question arises for the following problem (I was hoping to get away with using aliases)
Intro
I have defined a native SP
The OWXXCOLL schema is the same one I also use for tables/index...
(I noticed that the tables also have different aliases)
CREATE PROCEDURE OWXXCOLL.STORED1(...)
LANGUAGE SQL
ISOLATION LEVEL CS
WLM ENVIRONMENT FOR DEBUG MODE WLMENV1
ALLOW DEBUG MODE
BEGIN
...
END#
I also modified the cobol program (name:PGMSTO1) to call the Stored with the CALL statement (without qualifier)
EXEC SQL
CALL STORED1 (...)
END-EXEC.
The problem
The various table accesses (SELECT) work correctly BUT When I run the PGMSTO1 the call to the Stored ends with sqlcode -440
NO AUTHORIZED PROCEDURE BY THE NAME STORED1 HAVING COMPATIBLE ARGUMENTS WAS FOUND<
The error comes from the fact that it is not using the owner OWXXCOLL but DB2C (DB2C is user who scheduled the jcl/batch)
If I enter the qualifier (OWXXCOLL) the call it's OK.
I don't understand what to check and what configurations are missing.
Thanks
The cobol program (PGMSTO1) that calls the stored procedure has the following BIND parameters:
COLLID NAME OWNER CREATOR QUALIFIER DYNAMICRULES PATHSCHEMAS
OWXXCOLL PGMSTO1 DB2C DB2C FPXX B "DB2C"
"DB2C" path is used to resolve unqualified stored procedure
I will need to modify the bind parameter "PATH".
I will try to ask to add my schema as well (OWXXCOLL)
PATH("OWXXCOLL","DB2C")
I have a WindowsXPSP3 op system, on it a DelphiXE and InterbaseXE installed.
I created a database in IB and it works OK through the IBConsole and ISQL and connection testing also works through TCP/IP localhost:3050.
Now I try to access it from Delphi.
I did:
var AC:tADOConnection;
...
AC:=tADOConnection(Self);
AC.ConnectionString:=
AC.Open;
I tried all possible version I could google for the ConnectionString, but all generated an error. I used various Provider= versions, etc., but none works.
Could someone provide me with a simple working ConnectionString? Do I need to install any ADO driver or similar additionally?
Thanks,
Zsolt
There are two ways to easily create a valid connection string
a.1) Click on the small button in the object inspector right of the connection string property.
a.2) Create your connection, test it, press OK
or
b.1) Create an empty file e.g. 'TEST.UDL'. Use Notepad.EXE for example.
b.2) Double click on the file in the explorer. This will open the connection string editor
b.3) Create your connection, test it. Press OK
b.4) Your file now contains the connection string which you may copy&past in your application
Another benefit of the second method is that you can even use the file as a connection string. This makes life alot easier if you have to configure your connection from time to time (Just double click on the UDL if you have to change the connection properties). Here's how a valid connection string for a file looks like:
FILE NAME=<Full path to your UDL file>
I'm wondering if someone has an example on how can be used the TJvProgramVersionCheck component performing the check via HTTP.
The example in the JVCL examples dir doesn't show how to use HTTP
thank you
The demo included in your $(JVCL)\Examples\JvProgramVersionCheck folder seems to be able to do so. Edit the properties of the JVProgramVersionHTTPLocation, and add the URL to it's VersionInfoLocation list (a TStrings). You can also set up any username, password, proxy, and port settings if needed.
You also need to add an OnLoadFileFromRemote event handler. I don't see anything in the demo that addresses that requirement, but the source code says:
{ Simple HTTP location class with no http logic.
The logic must be implemented manually in the OnLoadFileFromRemote event }
It appears from the parameters that event receives that you do your checking there:
function TJvProgramVersionFTPLocation.LoadFileFromRemoteInt(
const ARemotePath, ARemoteFileName, ALocalPath, ALocalFileName: string;
ABaseThread: TJvBaseThread): string;
So you'll need to add an event handler for this event, and then change the TJVProgramVersionCheck.LocationType property to pvltHTTP and run the demo. After testing, it seems you're provided the server and filename for the remote version, and a local path and temp filename for the file you download. The event handler's Result should be the full path and filename of the newly downloaded file. Your event handler should take care of the actual retrieval of the file.
There are a couple of additional types defined in JvProgramVersionCheck.pas, (TJvProgramVersionHTTPLocationICS and TJvProgramVersionHTTPLocationIndy, both protected by compiler defines so they don't exist in the default compilation. However, setting the ICS related define resulted in lots of compilation errors (it apparently was written against an old version of ICS), and setting the Indy define (and then setting it again to use Indy10 instead) allowed it to compile but didn't change any of the behavior. I'm going to look more into this later today.
Also, make sure that the VersionInfoLocation entry is only the URL (without the filename); the filename itself goes in the VersionInfoFileName property. If you put it in the URL, it gets repeated (as in http://localhost/Remote/ProjectVersions_http.iniProjectVersions_http.ini, and will fail anyway. (I found this while tracing through the debugger trying to solve the issue.)
Finally...
The solution is slightly (but not drastically) complicated. Here's what I did:
Copy JvProgramVersionCheck.pas to the demo folder. (It needs to be recompiled because of the next step.)
Go to Project->Options->Directories and Conditionals, and add the following line to the DEFINES entry:
USE_3RDPARTY_INDY10;USE_THIRDPARTY_INDY;
Delete the JvProgramVersionHTTPLocation component from the demo form.
Add a new private section to the form declaration:
private
HTTPLocation: TJvProgramVersionHTTPLocationIndy;
In the FormCreate event, add the following code:
procedure TForm1.FormCreate(Sender: TObject);
const
RemoteFileURL = 'http://localhost/';
RemoteFileName = 'ProjectVersions_http.ini';
begin
HTTPLocation := TJvProgramVersionHTTPLocationIndy.Create(Self); // Self means we don't free
HTTPLocation.VersionInfoLocationPathList.Add(RemoteFileURL);
HTTPLocation.VersionInfoFileName := RemoteFileName;
ProgramVersionCheck.LocationHTTP := HTTPLocation;
ProgramVersionCheck.LocationType := pvltHTTP;
VersionCheck; // This line is already there
end;
In the ProgramVersionCheck component properties, expand the VersionInfoFileOptions property, and change the FileFormat from hffXML to hffIni.
Delete or rename the versioninfolocal.ini from the demo's folder. (If you've run the app once, it stores the http location info, and the changes above are overwritten. This took a while to track down.)
Make sure your local http server is running, and the ProjectVersions_http.ini file is in the web root folder. You should then be able to run the demo. Once the form appears, click on the Edit History button to see the information retrieved from the remote version info file. You'll also have a new copy of the versioninfolocal.ini that has the saved configuration info you entered above.
Microsoft has recently broken our longtime (and officially recommended by them) code to read the version of Excel and its current omacro security level.
What used to work:
// Get the program associated with workbooks, e.g. "C:\Program Files\...\Excel.exe"
SHELLAPI.FindExecutable( 'OurWorkbook.xls', ...)
// Get the version of the .exe (from it's Properties...)
WINDOWS.GetFileVersionInfo()
// Use the version number to access the registry to determine the security level
// '...\software\microsoft\Office\' + VersionNumber + '.0\Excel\Security'
(I was always amused that the security level was for years in an insecure registry entry...)
In Office 2010, .xls files are now associated with "“Microsoft Application Virtualization DDE Launcher," or sftdde.exe. The version number of this exe is obviously not the version of Excel.
My question:
Other than actually launching Excel and querying it for version and security level (using OLE CreateOLEObject('Excel.Application')), is there a cleaner, faster, or more reliable way to do this that would work with all versions starting with Excel 2003?
Use
function GetExcelPath: string;
begin
result := '';
with TRegistry.Create do
try
RootKey := HKEY_LOCAL_MACHINE;
if OpenKey('SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe', false) then
result := ReadString('Path') + 'excel.exe';
finally
Free;
end;
end;
to get the full file name of the excel.exe file. Then use GetFileVersionInfo as usual.
As far as I know, this approach will always work.
using OLE CreateOLEObject('Excel.Application'))
you can get installed Excel versions by using the same registry place, that this function uses.
Basically you have to clone a large part of that function registry code.
You can spy on that function call by tools like Microsoft Process Monitor too see exactly how does Windows look for installed Excel - and then to do it exactly the same way.
You have to open registry at HKEY_CLASSES_ROOT\ and enumerate all the branches, whose name starts with "Excel.Application."
For example at this my workstation I only have Excel 2013 installed, and that corresponds to HKEY_CLASSES_ROOT\Excel.Application.15
But on my another workstation I have Excel 2003 and Excel 2010 installed, testing different XLSX implementations in those two, so I have two registry keys.
HKEY_CLASSES_ROOT\Excel.Application.12
HKEY_CLASSES_ROOT\Excel.Application.14
So, you have to enumerate all those branches with that name, dot, and number.
Note: the key HKEY_CLASSES_ROOT\Excel.Application\CurVer would have name of "default" Excel, but what "default" means is ambiguous when several Excels are installed. You may take that default value, if you do not care, or you may decide upon your own idea what to choose, like if you want the maximum Excel version or minimum or something.
Then when for every specific excel branch you should read the default key of its CLSID sub-branch.
Like HKEY_CLASSES_ROOT\Excel.Application.15\CLSID has nil-named key equal to
{00024500-0000-0000-C000-000000000046} - fetch that index to string variable.
Then do a second search - go into a branch named like HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}\LocalServer ( use the fetched index )
If that branch exists - fetch the nil-named "default key" value to get something like C:\PROGRA~1\MICROS~1\Office15\EXCEL.EXE /automation
The last result is the command line. It starts with a filename (non-quoted in this example, but may be in-quotes) and is followed by optional command line.
You do not need command line, so you have to extract initial commanlind, quoted or not.
Then you have to check if such an exe file exists. If it does - you may launch it, if not - check the registry for other Excel versions.
I am trying to open and refresh an excel 2003 spreadsheet via ole. However I am getting the error "Add method of Workbooks class failed" with no further information.
The code works in unit tests, and works on 3 servers but fails with the error on our web server. It is being run from a service app running under the Local System Account.
The same version of excel is installed on all servers (2003 sp3). The file(s) in question all exist and are at the expected location.
There are no macros in the spreadsheets, but there are database queries. The spreadsheets can all be opened.
The calling code is
if VarIsEmpty(XLApp) then
begin
XLApp := CreateOleObject('Excel.Application');
try
XLApp.DisplayAlerts:= wdAlertsNone;
except
...
end;
XLApp.AutomationSecurity:= msoAutomationSecurityForceDisable;
end;
fullFileName:= ExpandReportFileName( partialFilename);
if not FileExists(fullFileName) then
raise Exception.Create('File not found: ' + fullFileName);
XLAPP.Workbooks.Add(fullFileName); << fail here
Any ideas on what else I can try?
I had been getting the same error for
xls.WorkBooks.Add(xlWBATWorksheet);
I changed that line to
xls.Application.Workbooks.Add;
Now it is working. You might try to get a Workbook first then try to call its methods.
Automating Office applications in a service is not supported.
While it is possible, it's very difficult, and you'll run into many problems, such as this one. It'll also be very slow.
You should look for a Delphi component that manipulates Excel files.
Depending on what you're trying to do, you might be able to use OLE DB instead.
Workbooks.Open might be the method you're looking for
Add creates a new empty workbook. If you supply a filename, that file is used as a template for the new file - see here
Open just opens the file as you would expect - see here
I ran into this error when I happened to have the Excel spreadsheet file selected in a Windows Explorer window, not open, just selected. When I deselect the file, I do not get the error.