I am completely new to Firebird; I have been given a Firebird 2.5 database (by our client) - XYZ.fdb
I have registered this XYZ.fdb database in IB Expert.
I am able to run successfully some views and stored procedures. However for some other views or stored procedure, I get the following error:
can't format message 13:896 - message file C:Windows\firebird.msg not found;
invalid request BLR at offset 623; function LTRIM is not defined; module name or entrypoint could not be found; Error while parsing procedure XXXXXXX (stored_procedure name) ;
Error Message:
Access violation at address 00DCA0E5 in module 'IBExpert.exe'. Read of address 00000000.
It was working fine last week; I had tried to restart the system, and install Firebird and IB expert over and over again; I get the above error for a few stored procedures and views, but the other views and stored procedures are working fine.
Since I did not have this issue last week, and in between I reinstalled Firebird and IB Expert a couple of times, I think it has some configuration or registration issue.
Can you provide me a step by step approach to fix this issue - such that I can access all database objects in the Firebird DB using IB Expert ?
The resulting error might be created by an access violation from IBExpert, but the reason is definitely a missing UDF library, for example a .dll file called rfunc.dll or freeadhocudf.dll or whatever it is called.
To find the name of the missing .dll, check the UDFs used in the database by clicking on UDF folder in IBExpert database registration.
Related
I have got this problem with FireDAC -> FDQuery component when it tries to select data from a database with '.' (dot) in its name.
The database name is TEST_2.0 and the error on Opening the dataset says:
Could not find server 'TEST_2' in sys.servers [...]
I have tried {TEST_2.0} (curly brackets) and [TEST_2.0] (square brackets). Also setting QuotedIdentifiers (Format Opetions) property to True does not seem to fix the problem. In SQL query I can add 'SET QUOTED_IDENTIFIER ON;' but this breaks inserts to the dataset.
The FDConnection component can connect to that server and that database using MSSQL driver without problems. It seems it is the dataset that dosn't handle it. UniDAC seems to handle everything without any problems.
I am using RadStudio 10.2.
Has anyone found any solution to this? Thanks in advance for any replies
I got a response from Emarcadero and it works for me:
"The problem is not in FireDAC, but in SQL Server ODBC driver
SQLPrimaryKeys function. It fails to work with a catalog name
containing a dot. FireDAC uses this function to get primary key fields
for a result set, when fiMeta is included into FetchOptions.Items. So,
as a workaround / solution, please exclude fiMeta from
FetchOptions.Items."
What is wrong?
I was able to reproduce what you've described here. I've ended up on metainformation command, specifically the SQLPrimaryKeys ODBC function call. I have used SQL Server Native Client 11.0 driver connected to Microsoft SQL Server Express 12.0.2000.8, local database server instance.
When I tried to execute the following SQL command (with TEST_2.0 database created) through a TFDQuery component instance with default settings (linked connection object was left with empty database connection parameter) in Delphi Tokyo application:
SELECT * FROM [TEST_2.0].INFORMATION_SCHEMA.TABLES
I got this exception raised when the SQLPrimaryKeys function was called with the CatalogName parameter set to TEST_2.0 (from within the metainformation statement method Execute):
[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL
Server]Could not find server 'TEST_2' in sys.servers. Verify that the
correct server name was specified. If necessary, execute the stored
procedure sp_addlinkedserver to add the server to sys.servers.'.
My next attempt was naturally modifying that CatalogName parameter value to [TEST_2.0] whilst debugging, but even that failed with similar reason (just failed for the name [TEST_2), so for me it seems that the SQLPrimaryKeys ODBC function implementation with the driver I've used cannot properly handle dotted CatalogName parameter values (it seems to ignore everything after dot).
What can I do?
The only solution seems to be just fixing ODBC drivers. Workaround I would suggest is not using dots in database names (as discussed e.g. in this thread). Another might be preventing FireDAC from getting dataset object metadata (by excluding fiMeta option from the Items option set). That will bring you the responsability of supplying dataset object metadata by yourself (at this time only primary key definition).
I am getting an error while trying to execute a dynamic insert query in volt db using the voltQueueSQLExperimental() function. The SQL is fine as i ran it separately on the volt web studio. The error is as follows:
Error: VOLTDB ERROR: USER ABORT Attempted to queue DML adhoc sql
'insert into volt_temp_constraints
(asset_id,config_id,session_id,sam_id) values (12,13,'abc',12)' from
read only procedure at
procedures.testPrcUpdateConstraint.run(testPrcUpdateConstraint.java:155)
Please note that the SQL generated is dynamic and adhoc and this cannot be generated statically before hand.
Documentation is not their strength... ;), but I could reproduce your bug.
As I see it VoltDB marks compiled Procedures as read-writer or read-only. As one can infer from here. Unfortunately there currently does not seem to be any other way around it other than creating a INSERT/UPDTE/UPSERT SQLStatement as a Object Property and simply not using it.
Maybe you can contact one of the developers to add a some way on confutation for this.
By the way, the Exception can be found here: https://github.com/VoltDB/voltdb/blob/master/src/frontend/org/voltdb/ProcedureRunner.java in line 620
I'm writing an application that has to open a preexisting BDE database that has been saved by a third party.
In this application, I currently have a TDatabase (DriverName: STANDARD) with path set correctly in Params.
I can now set Connected to true without an error message.
There is also a TTable with DatabaseName set to the values of the TDatabase and TableName set to the .db-file that lies in the folder (the name was automatically filled in, I only hat to select it).
Now the problem:
If I set Active to true, an error message complains about missing access rights for C:\PDOXUSRS.NET.
I know I could set another path using BDEADMIN, but I need to solve this in my application - I can't expect every customer to do this change.
Furthermore, I have a test machine with the third party application running - it can access the database without any error, while my application throws the aforementioned error. This leads me to the suspicion there might be a workaround.
Is there such a workaround?
I only need read access to the database.
Solved it thanks to the link of bummi
Thank you very much.
Quote:
How to change NET DIR programmatically so it persists
[...]
You should also remember that if you have programs that change their own NET DIR locations at runtime, using either the DbiSetProp function or the NetFileDir property of a TSession component, this will override the NET DIR value in the configuration file.
It pointed me to the possibility of changing the NET DIR in code:
Session.NetFileDir := MyCustomTempDir;
After doing that, Table1.active := true works and the data shows up in a connected TDBGrid.
I am working on an existing SSIS package to add custom logging to it. I am trying to test it, and I have an Execute SQL Task that I didn't create that is getting the following error.
Executing the query
"ap_pfl_DropProfileTables"
failed with the following error:
"Could not find stored procedure 'ap_pfl_DropProfileTables'.".
Possible failure reasons: Problems with the query, "ResultSet"
property not set correctly, parameters not set correctly, or
connection not established correctly.
I have no idea why I'm getting this error because:
I didn't create this or change it and this package is running without error in production.
The stored proc just truncates two tables. It doesn't have a result set or parameters.
The connections are working properly because this stored proc runs at the same time as another thread running a data flow task which runs successfully and uses the only two connections in this package.
I've double and triple checked the database to make sure the stored procedure is there and spelled correctly. I even checked the case of the letters in the stored procedure.
Any ideas on how to fix this?
I know this is an old thread but I have just run into this issue when using SSIS on SQL 2008 R2.
For me with an ADO.NET connection, I actually had to set IsQueryStoredProcedure to False and then the error went away. It didn't matter whether I used EXEC or not.
Yes this is frustrating - but Do-able. The key is to NOT use ADO.NET connection manager but instead use the good old fashioned ADO connection manager. The 2nd key is to NOT use EXEC or EXECUTE in the SQLStatement property of the Execute SQL Task editor. Just type in the name of the stored procedure (also for good measure use the 3-part name convention database.schema.storedprocedure. )
I haven't tried this with params on the stored procedure. Also, I have not tried this with the OLE DB connection manager.
I ran into this myself, and here is what I did (with the ADO.NET connection)
In the SQLStatement field I put the name of my stored procedure (dbo.myStoredProc).
I then set the IsQueryStoredProcedure property to "True"
I'm thinking that when IsQueryStoredProcedure is set to true the object automatically prepends EXEC to identify that the command is a stored procedure call.
After having the same issue I did some investigation on this:
Specifically my situation is:
I need to use ADO.Net because I am running against SQL Azure
I want to capture the stored procedure return value
First I tried this:
In SQLStatement I put the proc name (without EXEC)
myschema.MyProc;
In IsQueryStoredProcedure I put False
In ResultSet I put None
In the Parameter Mapping tab I put
Variable Name Direction Data Type Parameter Name Parameter Size
User::MyVariable ReturnValue Int32 0 -1
This runs without error, but does not capture the return value.
I assume if you set IsQueryStoredProcedure to true, it should wire all this up properly. But it returns an error instead.
This https://technet.microsoft.com/en-us/library/cc280502(v=sql.110).aspx, says for capturing the return value when using ADO.Net"Set IsQueryStoreProcedure is set to True". But it returns the error that is the OP
As a workaround I did this:
DECLARE #R INT
EXEC #R = MySchema.MyProc;
SELECT #R
I left IsQueryStoredProcedure as False
I set ResultSet to singlerow
I removed the parameter mappings and instead mapped a resultset:
Result Name Variable Name
0 User::MyVariable
I have an intermittent problem when calling an iSeries stored procedure (consisting of various CL & RPG programs). The error is:-
Commitment definition *N not valid for open of QAOSSI12
Error occurred while opening file QAOSSI12.
As mentioned the problem does not always occur but occurs more when load testing the procedure.
I know the information is vague but any ideas appreciated!!
If this is error CPF4326, the message text gives the following possibilities:
Member QAOSSI12 was opened for commitment control when commitment definition *N was not active.
Uncommitted changes are pending for member QAOSSI12 for a commitment definition other than *N.
The calling program is using commitment definition *N which has a scope of *ACTGRP, while the program specified to open the file using ascope of *JOB.
Are these situations possibles in your case?
We've been getting CPF4326 and the solution that seems to be working is to add "transaction isolation=none" to our jdbc URL. We aren't trying to use transactions anyway, so there's no benefit to having them enabled. We're also suspicious that something in iBATIS is trying to rollback the transaction when there is an error, even though we don't do anything explicit as far as commitment control.
You can change COMMIT value at compile time to COMMIT(*NONE) then no commitment definition is created .
The Commit (COMMIT) command is used to complete the current transaction and to establish a new commitment boundary for the commitment definition associated with the program issuing the command.
You have to check also if your file in under Journal.