I have a small Access 2007 database that I need to be able to import data from an existing spreadsheet and put it into our new relational model. For the most part this seems to work pretty well. Part of the process is attempting to see if a record already exists in a target table using SQL. For example, if I extract book information out of the current row in the spreadsheet, it may contain a title and abstract. I use SQL to get the ID of a matching record, if it exists.
This works fine except when I have data that's in a non-English language. In this case, it seems that there is some punctuation that is causing me problems. At least I think it's punctuation as I do have some fields that do not have punctuation and are non-English that do not give me any problems.
Is there a built-in function that can escape these characters? Currently I have a small function that will escape the single quote character, but that isn't enough. Or, is there a list of Unicode characters that can interfere with how SQL wants data quoted?
Thanks in advance.
It is pretty simple, All you have to do is to put a 'N' character before command like
select * from productswhere id = N'متن یونیکد'
'N' force sql to search Unicode
Related
I have imported a few thousand records in my existing CRM database from CSV and apparently all leading zeroes in the phone numbers column have disappeared. In searching for an answer all other questions I could find were about fixed length of the string. but my phone numbers vary in length. The ones that need their leading zeroes back are the ones starting with different than zero number. The old records (prior to my CSV import) are fine and I do not need another zero to go in front of them.
Please bare in mind I am not a programmer and this is all very difficult to me - even to explain.
I've tried to export the database table via phpmyadmin in CSV and sort the problem out in LibreOffice and then put it back (import) ...but there are records NULL that are not in quotes "" when exported and when I save the file in LibreOffice all fields are in quotes including the NULL ones. So I guess this will not work. It is a production environment. The table in question is the "contacts" table for a SugarCRM CE database. The field is varchar(100). So to summarize my question is: is there a function that I can put in phpmyadmin or in the terminal (i have root access), that will identify the records in this particular table (contacts), that start with number different than zero and ad one zero in front?
I know that I am expected to show a code that I've tried and to give some feedback what the result is, but I just can't. Sorry. Any help will be highly appreciated.
UPDATE table1 SET phone = CONCAT("0", phone) WHERE LEFT(phone, 1) <> "0";
You can first run SELECT with the same condition to see if it correctly return the rows that have phone numbers that lost their leading zeros
I need to take a microsoft word file and insert an image under It in a certain position (with delimited chars or someting like that). Then save that.
This is possible with Oracle Forms 6i? My database is 11G.
If this is not possible, can I read a certain amount of text under the word file and then put it into another, then save the new file?
Thanks in advance
No, it can't. But you can use Oracle Reports to make something that looks like your Word Doc, and then use your database to populate the specific data you need and save it wherever you want.
Otherwise if you're going to use Word, you need to setup the connection to your database in Word. But your question is a little too vague to give you a complete answer.
I'm using MySQL with XAMPP and using phpmyadmin to extract data from tables. If I choose to export to CSV, the data appears to be fine. But when I select to export using the "CSV for MS Excel" option, I'm losing some data in the export file. Settings are the same in both cases.
Specifically, if a field has a comma in it, it appears that at least sometimes the data after the comma is dropped. Note that the comma is contained in quotes with other text in the standard CSV format, so the comma should not be seen as a field delimiter. The data after the comma within the field is dropped, but in addition, data in fields that follow the field with the comma are also dropped, but not necessarily for the entire record.
So, let's say record 2 has a comma in a text-based field in column C, such as "big spender, nice guy." What goes into Column C in Excel is "big spender" with ", nice guy" being dropped. In addition, Columns D, E, F and G may also lose their data. But in some cases it appears that later columns (perhaps H, I, J and K) may have the correct data in them. I'm not suggesting it always loses data for any specific number of columns, just that some number seem to lose data but at times later columns start having data again in the correct column.
I can't see a clear pattern to what gets dropped and what doesn't, just that what I describe above happened yesterday in a data set I'm using. Note I can see the complete data in the SQL table, and if I use the straight CSV export, it appears that no data is lost.
Could this be a bug? I've searched for known bugs and found none. FYI, I'm using Excel in Office 2007 on a Windows 7 machine. The original data source is SugarCRM.
Thanks so much.
Open up the CSV file phpmyadmin made for you with a text editor, not with Excel. Find the offending row (the one with big spender, nice guy in it). Look to see whether it looks like this
"whatever","whatever","big spender, nice guy", 123, 456
or
whatever,whatever,big spender, nice guy, 123, 456
If it's the second one your columns aren't delimited properly. CSV is deceptively hard to get right because of this, and because of the possibility of this kind of text string:
Joe said, "O'Meara is a big spender and a nice guy!"
You may wish to try exporting your data in a tab-delimited rather than comma-delimited file to overcome this. You can do this by specifying ordinary, not Excel-style, CSV. Then specify
\t
where it ask you for "Columns separated with:".
Excel will be able to figure this out as it reads it.
I am reworking and expanding a somewhat complex database schema that has a small number of tables and queries but they are closely related. The only problem I had with it was that in one of the tables the 2 fields that were relating to another table were using the field name of the record and not the ID of the record.
I changed the referring fields data type from text to number and entered some data. The queries and the reports work fine with 1 exception:
There is one report that uses both referring fields. One of the fields is ok but the other one shows symbols instead of numbers. ( The IDs in my sample entries were 14 and 20 and the symbols shown were a double barred music note /alt code 14/ and the symbol for an end of a paragraph /alt code 20/ ) Investigating further I have found that if I make a query that contains the query source for the report both fields display fine, but if I add another table to that query the second field once again shows symbols instead of numbers.
I have found a workaround of this by converting those fields back to text and the id fields in the other tables to text as well. This text key will probably haunt me later on, so I'd like to make it right before it is too late.
This is all access 2010 btw. The source file was already in 2010 (couldn't open in 2007 even)
Sounds like a corruption issue for sure. I would try adding a new column and run an update query to populate it with the values from the old column (maybe use cint(indexfield)), then delete the old column.
It might also be a good idea to decompile the database. This often helps resolve corruption issues.
MS Access appears to support nulls in code, but I can't for the life of me figure out how to enter a null directly in a table. This is maddening because once a field has had a figure entered in it, it can never be deleted/set to null. Normally, allowing zero length strings would take care of this, but Access treats the XML export of a null and a zero length string differently. A null eliminates the associated XML tag and a zero length string sends an empty tag.
Does setting the "Allow zero length string" option in the table definition help? It may force an empty string to be interpreted as NULL.
Are you talking about needing to do it in Datasheet view? If you needed to do it in an update query, you can do it like this:
UPDATE test SET test.test = Null;
press ctrl-0 and a null is inserted.
Deleting all the characters will work, but Access is a bit fickle. Hitting backspace or delete will not work unless there are characters in the field. I find it is best to enter a few characters, select all, and hit delete, change focus and change the record. After all the above, if you run a query looking for "is null" the record will be found.
I'm actually looking for a way for a layperson to do the entry directly in a table. In MSSQL you can simply press ctrl-0 and a null is inserted. Deleting all the characters doesn't appear to work. Instead of a null, you are left with an empty string. They are not treated the same by Access for export purposes.
I think what I'm going to wind up doing is creating an xslt file to use during export that eliminates empty tags. That way the user can't really tell the difference.
It sure would be nice, though, to be able to key in a null.
Ok, I don't think this is an easily solvable problem and my original question was a little off target. The problem isn't so much with nulls, although they are involved, as with the manner in which the table was originally created. If you use an xsd file to create your tables you plan on exporting, something happens under the hood in Access that causes those fields to be treated a little differently than fields created with the editors.
The only solution I found was to create a new field in the table, rename the old field, copy the data from the old field to the new field and delete the old field.
After doing that, then blank fields that had data in them at one point are no longer included in the XML output. It's probably not the best way to do this, and I still don't know exactly why it's happening, but at least I can get past the issue.
Just delete all characters in the column and access will insert a null value for you if the coumn allows it.