Import from US7ASCII to AL32UTF8
Database version: 9.2.0.8 on SUN Solaris
I'm encountered the below error when impoting the data from US7ASCII to AL31UTF8. There are three tables hit with this error and these three tables have multiple VARCHAR2(4000) columns. How can I resolve this issue?. Is this issue exist on 10.2.0.3 too?.
IMP-00058: ORACLE error 1461 encountered
ORA-01461: can bind a LONG value only for insert into a LONG column
IMP-00028: partial import of previous table rolled back: 2679 rows rolled back
I have already gone through the Metalink Note 444171.1. But, my Oracle version is 9.2.0.8. Also, the mentioned cause will not be my case.
Cause
This is because of Bug 6167249. To confirm the Bug:
1) Table must be having at least one LOB column.
2) Table is precreated in destination database and Import is done with ignore=y parameter.
The two reasons are not true for my case. There are no LOB or LONG datatypes. The datatypes in columns are NUMBER and VARCHAR2 only. But, few columns are with VARCHAR2(4000). When, it's trying to to convert to UTF8, the columns with the length over 1333 may raise this error. Is any workaround for this issue.
Similar Messages
-
ORA-01461 while importing from UTF8 to AL32UTF8
Hello All,
Source Env: 9i on Solaris
Dest Env: 10.2.0.3 on Solaris 10
We have a table in a UTF8 database(9i).
While trying to import it into a AL32UTF8, it terminates with
IMP-00058: ORACLE error 1461 encountered
ORA-01461: can bind a LONG value only for insert into a LONG column
IMP-00028: partial import of previous table rolled back: 9170 rows rolled back The table has a column with LONG datatype.
Is this error because of the characterset conversion ?
TIA,
JJSrini,
I checked that already.
This table does not have LOB datatype. Only NUMBER,VARCHAR2,DATE and LONG.
Moreover, i tried with and without pre creating the table. Both ways result in this error.
TIA,
J J -
Changing database character set from US7ASCII to AL32UTF8
Our database is running on Oracle database 10.1.0.4.0 (AIX) The following are its parameters:
SQL> select value from NLS_DATABASE_PARAMETERS where parameter='NLS_CHARACTERSET';
VALUE
US7ASCII
We would like to change the database character set to AL32UTF8. After following Metalink notes: 260192.1 (which helped us resolve "Lossy" and "Truncated" data, the final output of the CSSCAN utility is:
[Scan Summary]
All character type data in the data dictionary are convertible to the new character set
All character type application data are convertible to the new character set
[Data Dictionary Conversion Summary]
The data dictionary can be safely migrated using the CSALTER script
We have no (0) Truncation and Lossy entries on the .txt file. We only have Changeless and Convertible. Now accdg to the documentation, we can do a FULL EXP and FULL IMP. But it did not detail how to do the conversion on the same database. The discussion on the document tells how to do it from one database to another database. But how about on the same database?
We cannot use CSALTER as stated on the document.
(Step 6
Step 12
12.c) When using Csalter/Alter database to go to AL32UTF8 and there was NO "Truncation" data, only "Convertible" and "Changeless" in the csscan done in point 4:)
After performing a FULL export of the database, how can we change its character set? What do we need to do the the existing database to change its character set to AL32UTF8 before we import back our dump file into the same database?
Please help.There you are! Thanks! Seems like I am right in my understanding about the Oracle Official Documentation. Thanks!
Hmmmmm...when you say:
*"you can do selective export of only convertible tables, truncate the tables, use CSALTER, and re-import."*
This means that:
1. After running csscan on database PROD, i will take note of the convertible tables in the .txt output file.
2. Perform selective EXPORT on PROD (EXP the convertible tables)
3. Truncate the convertible tables on PROD database
4. Use CSALTER on PROD database
5. Re-import the tables into PROD database
6. Housekeeping.
Will you tell me if these steps are the correct one? Based on our scenario: This is what i have understood referring to the Official Doc.
Am i correct?
I really appreciate your help Sergiusz. -
Character set Conversion (US7ASCII to AL32UTF8) -- ORA-31011 problem
Hello,
We've run into some problems as part of our character set conversion from US7ASCII to AL32UTF8. The latest problem is that we have a query that works in US7ASCII, but after converting to AL32UTF8 it no longer works and generates an ORA-31011 error. This is very concerning to us as this error indicates an XML parsing problem and we are doing no XML whatsoever in our DB. We do not have XML columns (nor even CLOBs or BLOBs) nor XML tables and it's not XMLDB.
For reference, we're running 11.2.0.2.0 over Solaris.
Has anyone seen this kind of problem before?
If need be, I'll find a way to post table definitions. However, it's safe to assume that we are only using DATE, VARCHAR2 and NUMBER column types in these tables. All of the tables are local to the DB.
ThanksWe converted using the database using scripts I developed. I'm not quite sure how we converted is relevant, other than saying that we did not use the Oracle conversion utility (not csscan, but the GUI Java tool).
A summary:
1) We replaced the lossy characters by parsing a csscan output file
2) After re-scanning with csscan and coming up clean, our DBA converted the database to AL32UTF8 (changed the parameter file, changing the character set, switched the semantics to char, etc).
3) Final step was changing existing tables to use char semantics by changing the table schema for VARCHAR2 columns
Any specific steps I cannot easily answer, I worked with a DBA at our company to do this work. I handled the character replacement / DDL changes and the DBA ran csscan & performed the database config changes.
Our actual error message:
ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00210: expected '<' instead of '�Error at line 1
31011. 00000 - "XML parsing failed"
*Cause: XML parser returned an error while trying to parse the document.
*Action: Check if the document to be parsed is valid.
Error at Line: 24 Column: 15
This seems to match the the document ID referenced below. I will ask our DBA to pull it up and review it.
Please advise if more information is needed from my end. -
Datapump Network Import from Oracle 10.2.0 to 10.1.0
I have self-developed table bulk copy system based on dmbs_datapump API. It is pretty stable and worked very well for a long time on many servers with oracle 10.1.0. But some days ago we have installed new oracle server with oracle 10.2.0 and have noticed, that our system can't copy tables from new server to another servers. After some time of debugging we got description for our situation... dbms_datapump.open() call is failing with "ORA-39006: internal error" exception. dmbs_dapatump.get_status() returns more detailed description: "ORA-39022: Database version 10.2.0.1.0 is not supported."... We're really disappointed... what we can do to use dbms_datapump.open on 10.1.0 to copy table from 10.2.0?
P.S. We have tried to use different values (COMPATIBLE, LATEST, 10.0.0, 10.1.0) for version parameter of open()... but without luck...
Please, help, because we can't upgrade such many old servers to 10.2.0 and we really need to use this new server...
Thanks in advance,
Alexey KovyrinHello,
Your problem is about the Character Set.
WE8ISO8859P1 stores character in *1* byte but AL32UTF8 (Unicode) uses up to *4* bytes.
So, when you Import from WE8ISO8859P1 to AL32UTF8 you may have the offending error ORA-12899.
To solve it, you may change the option of the Datatype of your column. And choose the option CHAR
instead of BYTE (the default), for instance:
VARCHAR2 (100) --> VARCHAR2(100 CHAR)Then, you could import the data.
You may also change the parameter NLS_LENGTH_SEMANTICS to CHAR.
alter system set nls_length_semantics=char scope=spfile;Then, restart your database.
NB: Although the parameter nls_length_semantics is dynamic you have to restart the database so
that it's taken into account.
Then, you create the Tables (empty) and afterwards you run your Import.
Hope this help.
Best regards,
Jean-Valentin
Edited by: Lubiez Jean-Valentin on Mar 21, 2010 4:26 PM -
How to find out what was imported from a dump file
Hi.
I got the dump file from a group and they told me to import it. Import job went successfully without errors as following:
Import: Release 9.2.0.6.0 - Production on Mon Oct 16 20:53:12 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
Export file created by EXPORT:V09.02.00 via conventional path
Warning: the objects were exported by OPS$ORACLETS, not by you
import done in US7ASCII character set and UTF8 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
export server uses AL16UTF16 NCHAR character set (possible ncharset conversion)
. importing OPS$ORACLETS's objects into SYS
. importing BDS_APP's objects into BDS_APP
Import terminated successfully without warnings.
How do i find out what was imported from a dump file?another way would be to just list the contents of the dump file
imp user/pass file=dumpfile show=Y -
Problem in Database convertion from US7ASCII to UTF8
Hi,
We are facing the following problem while converting the database from US7ASCII to UTF8:
We have recently changed the database character set from US7ASCII to UTF8 for the internationalization
purpose. We ran the Character set scanner utility and it did report that some data may pose problems.
We followed the the below mentioned process to convert into UTF8 -
1) alter database character set utf8
2) alter database national character set utf8.
Now we find some problem while working with the old data in our application which is java based.
We are getting the following error "java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv".
We further analyzed our data and found some interesting things :
e.g.
DB - UTF8.
NL_LANG also set to UTF8.
Select name from t1 where name like 'Gen%';
NAME
Genhve
But when we find out the length of the same data it show like this
NAME LENGTH(NAME) VSIZE(NAME)
Genhve 4 6
The question is why is it showing length as 4 only and when we try to use a substr function
its extracting like the following :-
select name,substr(name,4,1) from t1 where name like 'Gen%';
NAME SUB
Genhve hve
We have execute the above queries on US7ASCII DB and it is working fine, length it shows 6
and using SUBSTR it extracts just 'h' as well.
We also used dump function on the UTF8 Db for the above query,,this is the result :-
select name,length(name),vsize(name),dump(name) from t1 where name like 'Gen%';
NAME LENGTH(NAME) VSIZE(NAME) DUMP(NAME)
Genhve 4 6 Typ=1 Len=6: 71,101,110,232,118,101
We checked a lot with the data and it seems 'h' (accented e) is posing the problem.
We want to know where is the problem and how to overcome this.
Further, we tried all of the following :
1)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute e became h
2)
Export Server: US7ASCII
Export Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: IMP 00016 error
3)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: did not set NLS_LANG / NLS_CHAR, so presumably US7ASCII as well
Import Server: UTF8
RESULT: Acute E became h
4)
Export Server: US7ASCII
Export Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Client: NLS_LANG=AMERICAN_AMERICA.UTF8 and NLS_CHAR=UTF8
Import Server: UTF8
RESULT: Acute e became h
5)
Tried using Update sys.props$
set value$='UTF8'
where name='NLS_CHARACTERSET'
RESULT: Acute e shows properly but it gives problem in the application
"java.sql.SQLException: Fail to convert between UTF8 and UCS2: failUTF8Conv"
Looking further it was observed the following:
when you try this command on a column 'city' in a table which contains 'Genhva' (note the acute e after n), it shows
command: select length(city), vsize(city),substr(city,4,1),city from cities
Result: 4 6 hva Genhva
if you see the value of substr(city,4,1) , you will see the problem. Also note that the length shows 4 and size shows 6. Moreover, when these records are selected through JDBC Driver, it starts giving problems.
6)
Actually the above (point no. 5) is similar to changing the character set of the database with 'ALTER DATABASE CHARACTER SET UTF8'. Same problem is observed then too.
7)
We have also tried to with another method, that is by changing the third byte of the export file which specifies the character set, to the UTF8 code by editing the export file with a Hexdecimal editor. After import the same problem has been observed as defined in (5) and (6) above.
We have no more ideas how to migrate without corrupting the data. Of course we have known the records where these characters occur through the Oracle's cssacn utility but we do not want to manually rectify each and every record by replacing it with an ASCII character. Any other idea as to how this can be accomplised?
Thanx
AshokThe problem you have is that although your original database is defined as US7ASCII, the data it contains is more than is covered by this code page (as the reply on Sept 4 to the previous posting already said).
This has probably happened because the client was also defined as US7ASCII, and when the DB and client are defined as having the same character set no conversion (or checdking) takes place when data is passed between them. However if you are using a Windows client then it will in fact be using Windows code page 1252 (Latin-1) or similar, and this allows many more characters, including h (accented e). So a user can enter all these characters and store them in the database, and similarly read them from the database, because data transfer is transparent.
When you did ALTER DATABASE CHARACTER SET UTF8 this will only change the label on the database, but not affect the contents. However only part of the contents are valid UTF8, any character above 7F (like h) is invalid. If your original client now uses the database, code page transformation will take place because the client and DB have different character sets defined. The invalid codes can then cause problems.
Without being able to explain what has happened in detail, it may help to see what your h (dec 232, x'E8') looks like. The actual data has not changed (you can see this as it is reported as 232). However the binary code there (11101000) is invalid UTF8. UTF8 encodes a character in 1 to 4 bytes, and the first bits in a UTF8 character tell how many bytes it uses. 0xxx tell it is one byte (same as the corresponding USASCII character), 110x that it uses 2 bytes, 1110 that it uses 3 bytes etc. So if you interpret what is there as UTF8 it looks like the first byte of a 3-byte character, which explains why the substringing is giving you the other 2 bytes as well.
Can you fix this without losing data? I believe yes. First you should check what other characters are being flagged by the scan. See if these are contained in another standard character set. If they are only Western European accentet characters then WE8ISO8859P1 is probably ok, but watch out for the euro sign which Windows has at x'80', an undefined character in ISO8859-1.
You can see the contents of the Microsoft Windows Codepage 1252 at: http://www.microsoft.com/globaldev/reference/sbcs/1252.htm
For a listing of the US-ASCII defined characters see http://czyborra.com/charsets/iso646.html and for ISO 8859-1 see http://czyborra.com/charsets/iso8859.html#ISO-8859-1
If all is well, you can first ALTER DATABASE CHARACTER SET to WE8ISO8859P1. This will not change any data, but ensure that all the data gets exported. Then export the DB and import it to a UTF8 DB. This will convert the non-US-ASCII characters to Unicode. You will also have to change the clients character set to something other than USASCII or they will just see ? for the other characters.
Good Luck! -
Tables do not import when importing from 10gR2 to 9iR2
Hello forum members
I take full database dump from 10g database as below:
C:\Documents and Settings\Vugar>exp
Export: Release 9.2.0.1.0 - Production on Thu Aug 6 19:05:47 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Username: sys/sys_pass@prod as sysdba
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Produc
tion
With the Partitioning, OLAP and Data Mining options
Enter array fetch buffer size: 4096 >
Export file: EXPDAT.DMP > c:\full6.dmp
(1)E(ntire database), (2)U(sers), or (3)T(ables): (2)U > E
Export grants (yes/no): yes >
Export table data (yes/no): yes >
Compress extents (yes/no): yes >
And import the dump file in 9i database as below:
C:\Documents and Settings\Vugar>imp
Import: Release 9.2.0.1.0 - Production on Thu Aug 6 19:08:18 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Username: sys/sys_pass as sysdba
Connected to: Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Import file: EXPDAT.DMP > c:\full6.dmp
Enter insert buffer size (minimum is 8192) 30720>
Export file created by EXPORT:V09.02.00 via conventional path
import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
import server uses AL32UTF8 character set (possible charset conversion)
List contents of import file only (yes/no): no >
Ignore create error due to object existence (yes/no): no >
Import grants (yes/no): yes >
Import table data (yes/no): yes >
Import entire export file (yes/no): no > Y
Everything goes alright, all of the users and their grants created in the target database. But the tables and other objects of users do not create. After the full import I import every user with the from user to user clause. After that all of the objects create under each user. Can anyone tell me the reason of that, why the objects of users do not create when perfomin full import?? What is my mistake in full importing?
Thanks.Shafi Rasulov wrote:
Thanks for reply
Virendra, I exported from 10g with 9i exp utility, so 9i exp utility doesn't export incompatible objects from 10g, so it is possible full export import from 10g to 9i.
Anand, as you say, I exported/imported with 9i utility from 10g. In tha documentation and another tutorials I haven't seen any notification about missing table and another objects in the export/import.
Pavan, as you say there is several ways for migrating from 10g to 9i but I'm interested in why full export/import doesn't create tables and another objects when I do.
I say again, after I full import, I import each user with the FROM USER TO USER statement and all of the objects are created under relevant user. I want to learn the reason why the tables and another objects are not created in full import??I don't have 9i database with me to check what is happening but there should not be any error if you have used proper binary of the right version to do the export. What are those "incompatible objects" that you are talking about which are not exported/imported? You don't need to use from user/to user, if you are going to mention a 10g schema and Full=y , your import would work properly.
HTH
Aman.... -
Clarification on Character set migration from US7ASCII to UTF8
Hi,
I need clarification on the below.
I need to migrate the database from US7ASCII to UTF8.
For this I ran csscan for user "TEST" as well as against full database.
Below log is the csscan output against full database. but my application is depended on TEST schema only. Shall I need to migrate SYS objects data as shown below or it's not required?. If required how to migrate these objects data?
Looking forward you help.
USER.TABLE Convertible Exceptional
SYS.METASTYLESHEET 58 TEST.Table_1 9 0
TEST.Table_2 11 0
TEST.Table_3 17 0
TEST.Table_4 11 0
[Distribution of Convertible Data per Column]
USER.TABLE|COLUMN Convertible Exceptional
SYS.METASTYLESHEET|STYLESHEET 58 0
Thanks,
SankarI think you need to migrate all schemas data not only one application schema because
the database character set is common to all CHAR, VARCHAR2, LONG and CLOB colums
for any tables in any schema.
In your case (US7ASCII to UTF8), you need to use export/import because:
Another restriction of the ALTER DATABASE CHARACTER SET statement is that it can be used only when the character set migration is between two single-byte character sets or between two multibyte character sets. If the planned character set migration is from a single-byte character set to a multibyte character set, then use the Export and Import utilities.
(see http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1009904) -
Hebrew Characters...Chars display as junk after import from 8i to 10g
Gurus,
I have a problem with a customer upgrade...
Background of the issue... the customer is an Agile PLM customer of version 8.5 (Agile PLM version 8.5). The database was hosted on oracle 8i. He is intending to upgrade from Agile 8.5 to Agile 9.2.2.4. During this process he has upgraded he db from Agile 8.5 to Agile 9.2.2.4, and has also shifted the DB platform from 8i to 10g.
Problem: There were hebrew characters entered in Varchar2 columns (Oracle 8i), which after upgrade are not displaying correctly. Newly entered hebrew characters after upgrade display correctly in UI...
Customer DB Parameters : The nls parameters on the source db before upgrade(8i) are American_America.WE8ISO8859P1, and the destination db parameters are American_America.UTF8.
What i have done to deal with the issue: i have tried exporting the db using UTF8 and importing the db to 10g on UTF8, but still the characters show as garble characters..., have tried various options of exporting/importing using the combinations of WE8ISO8859P1 char set as well as IW8ISO8859P8 charsets, as i have learnt during my research abt the charsets that Hebrew Characters are supported in IW8ISO8859P8 charset and not WE8ISO8859P1. My suspicion here is that the problem is with the export and import from 8i to 10g, and the Char conversion which is happening during this process..(this is my guess and i might be wrong tooo...)
Currently this is a hot issue with the customer, and needs an immediate fix (to display the Hebrew characters properly after upgrade)
I am a layman on the NLS Settings and couldnt figure out what else to do....I would request all the Gurus out there to help us figure out the problem and try resolve it...
Thanks for your Help in Advance
Regards,
Raja.Hebrew characters aren't supported using the ISO 8859-1 character set. In the original system, what must be happening is that the NLS_LANG on the client matches the database character set, which tells the Oracle client not to do character set conversion. This causes Oracle to treat character data just as a binary data stream and to store whatever bits the client sends. So long as the client is really sending ISO 8859-8 data, telling Oracle it is ISO 8859-1, and on the return side asking Oracle for ISO 8859-1 and treating it internally as ISO 8859-8 while Oracle is doing no character set conversions, this will appear to work. But the data in the database is fundamentally wrong. You can configure things so that you can, apparently, store Chinese data in a US7ASCII database using this sort of approach, but you end up with screwed up data.
This sort of problem usually comes to light when you start using tools (like export) that don't know how to mis-identify the data they are sending and retrieving like your application is doing or when character set conversion is necessary. Since the data in the database isn't valid ISO 8859-1, Oracle has no idea how to translate it to UTF8 properly.
As previously suggested, the safest option is to move the data with a solution that replicates the behavior of the application. So
- Set the client NLS_LANG to match the database character set (WE8ISO8859P1)
- Extract the data to a flat file using SQL*Plus or a C/C++ application
- This data file will, presumably, really be ISO 8859-8 encoded
- Use SQL*Loader to load the data into the UTF8 database, specifying the actual character set (ISO 8859-8) in the control file.
If you're rather more adventurous and working with Oracle Support, it is potentially possible to change the character set of the source database from ISO 8859-1 to ISO 8859-8 and then export and import will work properly. But this would require some undocumented options that shouldn't be used without Oracle Support being involved and introduces a number of risks that the flat file option avoids.
Justin -
How to export and import from AIX to solaris a whole schema with different
how to export and import from AIX to solaris a whole schema with different character set
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
Import terminated successfully with warnings.The conversion between the character sets on the two servers are handled automatically. Export from one server will export the data given the character set defined on that server. Import into another server will import the data given the character set defined on that server, performing a conversion if necessary. This can be a problem when going from single-byte to a multi-byte character set. In your case, the warning is simply for your information, shoule be no real problem given the character sets you're using.
For more info...check out (pertains to 9i):
Export
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96652/ch01.htm#1006791
Character Ste Migration
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch10.htm#1656
HTH -
Change Oracle XE from WE8MSWIN1252 to AL32UTF8
I want to change the character set of Oracle XE 10g on my machine from WE8MSWIN1252 to AL32UTF8. I understand I need to scan, change my NLS_LANG and export and them import into new XE with Universal character set.
I need some more details to these steps if someone can help out.
My current Oracle XE details:
NLS_LANGUAGE - AMERICAN
NLS_TERRITORY - AMERICA
NLS_CHARACTERSET - WE8MSWIN1252
I want NLS_CHARACTERSET to be AL32UTF8.
Thanks,Hi everbody,
Really OracleXE dont suport character convertion.
But I get the binary CSSCAN from another Oracle 10g Enterprise and copy to server of XE in $ORACLE_HOME/bin.
With this, I copy also CSALTER.PLB and CSMINST.SQL to ?/rdbms/admin and now, I have the scripts.
So, I run following the "howto" and read .log, .err and .out files generated from log=
If you receive the message "Checking or Converting phrase did not finish successfully", check the .err file and drop the tables listed as "with error". After this, the process run without erros and YES, the database is CHANGED.
I do this and I can afirm: this process works!
Ederson.Oliveira
www.rwit.com.br -
When I try to print a drawing imported from my ipad iphoto crops it. Is there any way to stop this?
When I try to print a drawing imported from my ipad iphoto crops it. Is there any way to stop this?
Usual cause: printing at the wrong aspect ratio for the image - trying to print 5 x 3 in the shape of a 6 x 4 for instance.
Regards
TD -
I want to remove all of my photos out of iPhoto there are approximately 35000 some imported from an old hard drive and a SD Card from my Nikon D500 how do I do this?
I have iPhoto version 9.1.5 (615)
Mac OS X version 10.6.8
I want to do this because when I imported from my old hard drive there was an error message stating that 12 photos were not imported as the programm did not recognise the format even though they were jpegs like the other photos in that particular album. The dates of the photo folders are wrong I have multiple copies of photos and every time I start iPhoto I get the following message 12 photos have been found in the iPhoto library that were not imported would you like to import them No or Yes
if you press Yes the same message comes back again and if you press Yes again the program flicks to last import for 2 seconds and then opens events.
if you press No the message The photos have been placed in the folder/user/judith/pictures/iphoto Library recovered photos then if you press OK the original message 12 photos have been found.............
if you press No at this point the message The photos have been placed in the folder/user /judith/pictures/iphoto Library recovered photos_11 the end number goes up by 1 every time you go through this process
Any help would be greatly appreciatedDid you import an iPhoto Library from the old Hard Drive? Do you still have that old Library?
The way to clear out a Library is to Export the photos - Apps like iPhoto2Disk or PhotoShare will help you export to a Folder tree matching your Events.
For the annoying start-up message:
Go to your Pictures Folder and find the iPhoto Library there. Right (or Control-) Click on the icon and select 'Show Package Contents'. A finder window will open with the Library exposed.
Look there for a Folder called 'Import' or 'Importing'.
Drag it to the Desktop. *Make no other changes*.
Start iPhoto. Does that help?
If it does then look inside that folder on your desktop. Does it contain anything you want? If not you can trash the folder. -
Comments not imported from Data Dictionary of SQL Server. SDDM 3.3.0.747
Hi,
SDDM 3.3.0.747 32-bit on Windows 7 64-bit.
Comments are not imported from Data Dictionary of SQL Server 2008. Connection through Microsoft JDBC Driver 4.0 for SQL Server or jTDS 1.2.7
What I have tried? In SDDM DDL generation, Comments in DBRMS for SQL Server are generated with "EXEC sp_addextendedproperty 'MS_Description' , 'Test Comment' ..." so I added extended property named "MS_Description" into SQL Server database, both on table and column. None of them were imported from Data Dictionary into SSDM. I have tried both drivers stated above. Is it a bug or am I missing something?
I've found similar question thread Re: Data dictionary import doesn't import column comments for SDDM 3.0.0.665, so I guess it is a bug when importing with JDBC drivers.
MiGli
Edited by: MiGli_1006342 on May 25, 2013 8:32 AM
Edited by: MiGli_1006342 on May 25, 2013 9:02 AMExtended properties were not imported correctly from SQLServer databases at DM 3.3.0.747.
Calls to sp_addextendedproperty and fn_listextendedproperty have been modified.
I don't think it is a problem with JDBC drivers.
A bug fix should be available in the next release of DM.
Maybe you are looking for
-
Hi, I would like to point weblogic to a directory NOT under c:\bea\... for it's configuration. I used to do this on WLS 5.1 by setting: weblogic.home=/weblogic and weblogic.system.home=/projects/wlsconfig This way my config was NOT coupled to the web
-
Does the time capsule work as an external hard drive that you can access from multiple lapttops
I have a mac desktop, a macbook and a pc laptop. I also purchased the time capsule. Will that functional as an external hard drive that I can use to save a share documents between. Trying to figure out the best way to work on documents between device
-
TS3276 mail messages often fail to display pictures and graphics?
i have a problem with some mail messages in that they do not display picture and graphics. i have Flip4Mac installed and have a late model Macbook Air 13 inch running Mavericks
-
MacBook Pro stalls during installation of update
After restart, shows "installing 3 items". Progress bar moved quickly to just shy of half and is now stalled. It has been like this for 4 hours even though it says time remaining is less than one minute. Help!
-
anyone tell me how to check the call & data log on this phone please? Id like to keep track of how much usage Ive made. It was fairly simple on previous older phones!