I've successfully connected to a IBM DB2 database in SPSS using the connection wizard. However, I haven't found a working method to do this using SPSS syntax. Has anyone any experience with this?
Normally you'd access it via this Syntax:
GET DATA /TYPE = - insert one of these types - ODBC,OLEDB,XLS,XLSX,XLSM,TXT
Whichever is the type that you wish to access, you can also use SQL within the SPSS syntax editor. This is how I connect to my database from the syntax:
GET DATA
/TYPE=ODBC
/CONNECT='DSN=MAVSQL;Description=SQL;UID=;APP=IBM SPSS Products: Statistics '+
'Common;WSID=MAVNEW;DATABASE=Players;Trusted_Connection=Yes'
/SQL='SELECT Id, Faction, Active, Level, Name, Allignment, CurQuest, '+
'PrevQuest, DeathCount, LastDeath, LastLogon, Created, Class, RacAB, '+ 'Comments, Test, Age, RealName, Email FROM dbo.DSOL'
/ASSUMEDSTRWIDTH=255.
CACHE.
EXECUTE.
DATASET NAME DataSet1 WINDOW=FRONT.
Hope that helps, I know the database I accessed is a SQL database but perhaps you can use the same methodology to access your IBM DB2 database.
Besides pasting the syntax shown in the last panel of the Database Wizard, which includes the connection string and the SQL that goes with the GET DATA command, you can save the query as an spq file from that last panel and use that again in the Database Wizard by choosing Edit Query in the first step.
Related
Using MS Access 2007 I would like to retrieve only part of an ODBC table.
I can import the whole table in Access but I don't need all of it and it would be a waste of space and performance to store the whole table when I only need certain columns.
In Excel I wrote a SQL query that let me retrieve only the part I'm interested in. What I'd like to know is: is it possible to import only the result of a SQL query in Access or do I have to retrieve the whole table and then run the query on it?
Is it possible using built-in Access module or should I turn to VBA?
Edit: Basically I would like to run the ODBC data connection below (currently used in Excel) in Access.
Connection string:
DSN=BLA1;
UID=BLA2;
DBQ=BLA3;
PWD=BLA4;
DBA=W;
APA=T;
EXC=F;
FEN=T;
QTO=T;
FRC=10;
FDL=10;
LOB=T;
RST=T;
GDE=F;
FRL=F;
BAM=IfAllSuccessful;
MTS=F;
MDI=F;
CSR=F;
FWC=F;
PFC=10;
TLO=0;
Command string:
SELECT *
FROM TEST TEST
WHERE (TEST.DATE_STAMP=?)
When I try to link the database I get the error The database engine can't find 'WTD.DATAPOINT_5/1000'. Make sure it is a valid parameter or alias name, that it doesn't include characters or punctuation, and that the name isn't too long. but when I use the Excel database connection I get no error and everything is updated.
You don't need to import the whole table. You could link to the ODBC table and then run a make-table query against that linked table to copy in only the rows and columns that you need.
I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.
Im trying to run the following to import a large volume of sales data in a text file into a database. When i run the following i get the error: "Invalid object name 'PetDatabase.Sales'
BULK INSERT PetDatabase.Sales
FROM 'C:\Temp\P1.txt'
WITH
(
FORMATFILE = 'C:\Temp\PetSales.Fmt'
);
Can anyone see whats causing my problem? I do have the tables within a folder; however, when i tried PetsDatabase.Tables.Sales it made no difference.
Ignore this answer. It was written when the question was tagged with mysql. Leaving the answer here to keep the comments.
--
Try using LOAD DATA INFILE instead.
http://dev.mysql.com/doc/refman/5.1/en/load-data.html
Make sure PetDatabase.Sales exists in your text file.
Swap for whichever row and field terminator delimiters you're using. Here I'm using delimiters from a comma separated file
BULK INSERT PetDatabase
FROM 'c:\temp\p1.txt'
WITH
(
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
GO
--Check the content of the table.
SELECT *
FROM PetDatabase
GO
--Drop the table to clean up database.
SELECT *
FROM PetDatabase
GO
Also, make sure the following doesn't apply to you:
If a SQL Server user is logged in using Windows Authentication, the user can read only the files accessible to the user account, independent of the security profile of the SQL Server process.
When executing the BULK INSERT statement by using sqlcmd or osql, from one computer, inserting data into SQL Server on a second computer, and specifying a data_file on third computer by using a UNC path, you may receive a 4861 error.
To resolve this error, use SQL Server Authentication and specify a SQL Server login that uses the security profile of the SQL Server process account, or configure Windows to enable security account delegation.
Is PetDatabase is schema name or database name?
If it is database name, then include schema name also like this if your schema name is dbo.
PetDatabase.dbo.Sales
Access 2007 databases querying linked oracle 10g tables are returning flawed result sets when using the WHERE clause to filter-out unwanted records. Oddly, some filtering is happening, but not reliably.
I can reliably demonstrate/produce the problem like this:
Create a *new* database with Access 2007.
Create a second *new* database with Access 2007, and then "save-as" 2000.
Create a third *new* database with an older version of Access.
Run the following query in each database:
SELECT
STATUS,
ID,
LAST_NAME,
FIRST_NAME
FROM
Oracle10g_table
WHERE
STATUS="A"
In both databases created with Access 2007, running this query will give you a result set in which some of the records where (STATUS="A") = false have been filtered out, but not all of them.
In databases created with older versions of access, the where clause filters properly, and the result set is correct.
STATUS is a text field
The table is a "linked" table to an Oracle10g Database
The table has 68k rows
I've tested my timeout at 60, 1000 and 0
Has anyone run into this problem?
I wonder if this is a new "feature" of access that will also affect 2010. Could this have anything to do with ODBC?
Thanks for any help,
- dave
MORE...
I just tried an alternate form of the query, using HAVING instead of WHERE, and it worked! Problem is, besides that this shouldn't change anything (yes -- more virtual tables, but shouldn't change the end result) my end-users will be using the Access 2007 visual query designer, not typing SQL directly, which is going to default any criteria they enter into a WHERE.
My hunch is that one of your ODBC drivers used by Access to connect to Oracle is treating "A" as a column name not the literal 'A'. Have you tried single quotes on the 'A'? In Oracle double quotes are used to reference column names, is there a column named "A" by any chance?
Oracle Query Example #1
Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'
Oracle Query Example #2
with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
I've had a similar problem. In my case, changing the ODBC driver worked, but I could also just change the 'unique record identifier' to a column with no nulls in it. It still doesn't have to be the "right" unique record identifier.
This turned-out to be an ODBC-related issue. Our tech support service unit installs connectivity on each of our workstations -- they program it themselves, and who knows what they actually put into it -- but the net result is that when you link to an ODBC datasource with Access (of any version), our network servers show-up in the 'machine data source' tab, so we just click on the one we want and away we go. This has worked well until Access 2007.
What I did was create a "new" machine data source, which let me choose the ODBC driver myself (instead of making me use the one our tech support folks created). I picked "Microsoft ODBC for Oracle", entered the name of the server I wanted, and that all it took. Now the WHERE-clause inconsistent filtering problem is solved (I hope).
The only thing remaining is to send this back to our tech support folks, so they can clean-up their installation. Should I ask for hazard pay? :-) hehe
I am trying to archive some of my tables into another database on the same server. However the INSERT INTO...SELECT...FROM gives me an error (SQLSTATE=42704) on build. The table exists in the second database.
Can anyone help with this?
It's not clear from your question what version of DB2 is being used. I'll presume that it's the Linux, Unix & Windows version. You look to be using federation to link the two databases.
Does the SELECT part of your query work from LS2DB001? It's worth trying to pin down which database you have the issue with.
Presuming that the problem is on LS2DB001, if the user you have defined the federated link with has permissions on the base tables in the query, check also that they have permissions on the system catalog tables. If not, they would not be able to parse and validate that you can run the query.
We've cracked it! If the following script is used then it works. The LOAD works without having to COMMIT in between batches of rows copied. ('Transaction Log full...' error problem is also solved)
CONNECT TO LS2DB001;
EXPORT TO "C:\temp\TIN_TRIGGER_OUT.IXF" OF IXF
MESSAGES "C:\temp\TIN_TRIGGER_OUT.EXM"
SELECT * FROM LS2USER.TIN_TRIGGER_OUT;
CONNECT RESET;
CONNECT TO LQIFCOLD;
LOAD FROM "C:\temp\TIN_TRIGGER_OUT.IXF" OF IXF
MESSAGES "C:\temp\TIN_TRIGGER_OUT.IMM"
INSERT INTO LS2USER.TIN_TRIGGER_OUT COPY NO INDEXING MODE AUTOSELECT;
COMMIT;
CONNECT RESET;
I found this on http://www.connx.com/products/connx/Connx%208.6%20UserGuide/CONNXCDD32D/DB2_SQL_States.htm:
42704 Undefined object or constraint name. Revise SQL syntax and retry.
For more help try to be more specific, eg paste the full sql statement, the table scheme etc.
You can do
Select 'insert into tblxxxx (blabla,blabal) values(' + fld1 + ',' + fld2 + ',' ...... + ')'
From tblxxxxxx
copy the result as a text script and execute it in the other DB.
The best way to do this would be to create a custom script. Depending on the size of the tables (how many records) you could either do a select of all of the data into memory and then roll over them inserting them into a copy of the table you create first, or you could export the data out as a csv file or some other text based file and then roll over that to insert the data into the other table.
If you do not have some sort of formal backup procedures that could do this already, this would be your best bet.
Note: some db2 databases, such as those on an iSeries do not actually have "databases", they have libraries. With the right user profile you can access two libraries at the same time, joining tables from them together or doing a
create table library/newFilename as
(select * from originallibrary/originalfilename) with data
But this only applies to the iSeries I believe.
I'm writing this response as another answer so I have more space.
I can only suggest breaking the steps down to their components, and working through to see where the error is occuring. Again, I'm assuming you're using federation:
a) In your FROM db, connecting as the user you're using for the federated link, does your select work?
b) In your TO db, using the link, does the select work?
c) In your TO db, using the link via a stored proc, does the select work?
d) In your TO db, using an INSERT...values(x,y,z), can you insert into the table?
e) In your TO db, via a stored proc, using INSERT...values(x,y,z), can you insert?
Without more information, this is the best line of attack I can suggest.