SSIS Flat File Export - Only need certain rows from file - ssis

I am using SQL Server 2012 and am trying to import a flat file and store it into the database. The problem I am having is that I only need certain rows in a file that contains much more data.
Here is an example from part of a file which I am trying to import.
12/02/2015 09:47:44:917 Rx: Message Header: Ver: 1, MsgType: 1, MsgId: 3 Status: 0x00
TranId: 6, Data ByteCount: 55
Data: 86 A6 4E 0B 6A 64 54 2E 00 50 00 02 00 00 60 1A E0 AD 10 12 BF 07 56 54 20 31 32 42 46 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 CB
Rx Cmd=84, Rsp code=0x00, Device Status=0x50
Sub-Device Index=2
IO Card=0
Channel=0
Manufacturer ID=24602
The only values I care about are ones which are delimited by = (Sub-Device Index, IO Card, etc.). In this example, how can I import the file in a way that the value 2 gets inserted into a column for Sub-Device Index, 0 inserted into a column for IO Card, 0 for Channel, etc.?

You can do this with a script task that reads and parses the file, and either populates SSIS variables for use with an Execute SQL task, or the script task can insert them directly into the database.

Related

How to communicate with a specific ECU using its physical address

Each time I send a query to the OBD2 I get two responses.
For instance, if I send 0105, I get
41 05 5C
7F 01 12
If I turn on header with AT H1 and then send 0105, I get
83 F1 11 41 05 5C
83 F1 18 7F 01 12
I only need the first response, the one from 83 F1 11
please, how do I specify that I want to communicate with only that ECU?
From "ELM Electronics - Circuits for the Hobbyist"
I know it should be done using AT SH but there are three options
available and I do not know which one to use:
AT SH xyz or AT SH xxyyzz or AT SH wwxxyyzz.
Btw my car is a Hyundai Tucson 2006, and runs protocol 5 that is
ISO 14230-4 KWP (fast init, 10.4 kbaud)
There are multiple ways. The most complicated one is setting the header address directly via ATSH. Way easier is appending the number of expected responses to the pid, i.e. 01001 will send 0100 and discards all but one response. The fastest ECU will win, which is not always what you want.
So another way is to filter by header, i.e.:
>0100
18 DA F1 10 06 41 00 B8 7B 30 10 00
18 DA F1 17 06 41 00 80 00 80 03 00
>AT CRA 18DAF117
OK
>0100
18 DA F1 17 06 41 00 80 00 80 03 00

SQLite3: Failing to import CSV on Mac

I'm a newbie to sqlite3 and I'm trying to play around with some data that I got my hands on.
I'm currently running into the problem in which I cannot even create my table in my shell. I'm trying to run
.mode csv
.import filename tab1
But I'm getting this error
CREATE TABLE tab1(...) failed: duplicate column name: B-
Since I'm importing a .csv file, I thought that perhaps I do have a duplicate in my column names but they all seem to be distinct to me. Can someone point me in the right direction? I would really appreciate it :-)
Here is a short excerpt of my .csv file:
SID,Name,Cohort,Email,Gender,Ethnicity,Major,Grades,More grades,Last grades,Not sure,,
24239361,name1,Cohort 1-Fall 2013,name1#email.com,Female,Chinese,CS,B,C+,B-,B-,,
24474707,name2,Cohort 1-Fall 2013,name2#email.com,Male,Chinese,CS,B,B+,B-,B-,,
24266062,name3,Cohort 1-Fall 2013,name3#email.com,Male,White,CS,B-,B-,C,B ,,
UPDATE:
Edited my csv file to now only be:
SID,Name,Cohort
24239361,Name1,Cohort 1-Fall 2013
24474707,Name2,Cohort 1-Fall 2013
24266062,Name3,Cohort 1-Fall 2013
22181134,Name4,Cohort 1-Fall 2013
And when I import it and do .schema, I get this:
CREATE TABLE foo(
"SID" TEXT,
"Name" TEXT,
24239361" TEXT,
"Name1" TEXT,
24474707" TEXT,l 2013
"Name2" TEXT,
24266062" TEXT,l 2013
"Name3" TEXT,
22181134" TEXT,l 2013
"Name4" TEXT,
24527147" TEXT,l 2013
This is really strange because I'm skipping over the header column "Cohort" and instead reading all of my following lines to columns
I can't reproduce your issue exactly, but when I try with your sample data I get the following not-quite-identical error:
CREATE TABLE tab1(...) failed: duplicate column name:
And the reason for that is those two commas at the end of your first line (representing the columns of the new table). SQLite tries to make two columns with blank names and fails on the second. The solution is to either remove those commas from every line of the file, or to give those fields valid column names.
I wasn't able to specifically reproduce your issue, but it looks like SQLite is not seeing that first line for some reason or another and is trying to set the columns up based on one of the next lines (which have multiple fields with value B-, causing the same issue as above). You'll need to track down why that's happening. Alternatively, you can create the table first, and remove the column heading line from the file before you import it:
CREATE TABLE tab1 (SID INTEGER, Name TEXT, ...);
.mode csv
.import filename tab1
The sqlite3 tool expects the new-line characters in CSV files to be CR+LF (as specified in RFC 4180).
Your file looks like this:
00000000: 53 49 44 2c 4e 61 6d 65 2c 43 6f 68 6f 72 74 0d SID,Name,Cohort.
00000010: 32 34 32 33 39 33 36 31 2c 41 6c 6c 69 73 6f 6e 24239361,Xxxxxxx
00000020: 20 43 6f 72 69 6e 6e 65 20 59 65 65 2c 43 6f 68 Xxxxxxx Xxx,Coh
00000030: 6f 72 74 20 31 2d 46 61 6c 6c 20 32 30 31 33 0d ort 1-Fall 2013.
00000040: 32 34 34 37 34 37 30 37 2c 41 6e 74 68 6f 6e 79 24474707,Xxxxxxx
...
This file has Mac line endings (only CR), which would be valid for a normal text file.
You can manually change the row separator after setting CSV mode:
.mode csv
.sep , \r

Mysql search for exact number in field

in my MySql DB, i have column containing that kind of value
63 61 57 52 50 47 46 44 43 34 33 27 23 22 21 10 5 3 2 1
Those numbers are separated by tab.
Impossible to get the good result for a simple query that would aid something like this
SELECT * FROM mytable WHERE mycolumn = 63
I'm not sure if "=" is the good method, i've also tried LIKE, IN and even FIND_IN_SET
I need some help :)

MySQL hanging when using UPDATE CASE WHEN for saving reordering list

I'm using MySQL UPDATE CASE WHEN ELSE statement to update an ordered list on my web application. I have a html table with the sortable drag-and-drop plugin, and on the stop event I hit a servlet that persists the new order to the MySQL Table.
The thing is that from time to time MySQL hangs when the user reorders the table very quickly. Like in the example below, there were 4 statements issued in the same second, and then it hanged.
22/01/2014 14:03:25 UPDATE `edited_table_name` SET `order` = CASE NR_DMD WHEN 92059 THEN 22 WHEN 124376 THEN 23 WHEN 124163 THEN 24 WHEN 127019 THEN 25 WHEN 123816 THEN 26 WHEN 124348 THEN 27 WHEN 127017 THEN 28 WHEN 126764 THEN 29 WHEN 126637 THEN 30 WHEN 122170 THEN 31 WHEN 125630 THEN 32 WHEN 125515 THEN 33 WHEN 124487 THEN 34 WHEN 124374 THEN 35 WHEN 124343 THEN 36 WHEN 124327 THEN 37 WHEN 126838 THEN 38 WHEN 126720 THEN 39 WHEN 126718 THEN 40 WHEN 123510 THEN 41 WHEN 122966 THEN 42 WHEN 124385 THEN 43 WHEN 122754 THEN 44 WHEN 124312 THEN 45 WHEN 122311 THEN 46 WHEN 121577 THEN 47 WHEN 121028 THEN 48 WHEN 123354 THEN 49 WHEN 121682 THEN 50 WHEN 120993 THEN 51 WHEN 120860 THEN 52 WHEN 120750 THEN 53 WHEN 120460 THEN 54 WHEN 120459 THEN 55 WHEN 120397 THEN 56 WHEN 119178 THEN 57 WHEN 111723 THEN 58 WHEN 127644 THEN 59 WHEN 127610 THEN 60 WHEN 127609 THEN 61 WHEN 127542 THEN 62 WHEN 125799 THEN 63 ELSE order END WHERE NR_DMD IN(92059,124376,124163,127019,123816,124348,127017,126764,126637,122170,125630,125515,124487,124374,124343,124327,126838,126720,126718,123510,122966,124385,122754,124312,122311,121577,121028,123354,121682,120993,120860,120750,120460,120459,120397,119178,111723,127644,127610,127609,127542,125799)
22/01/2014 14:03:25 UPDATE `edited_table_name` SET `order` = CASE NR_DMD WHEN 121419 THEN 10 WHEN 110378 THEN 11 WHEN 124376 THEN 12 WHEN 124163 THEN 13 WHEN 127019 THEN 14 WHEN 123816 THEN 15 WHEN 124348 THEN 16 WHEN 127017 THEN 17 WHEN 126764 THEN 18 WHEN 126637 THEN 19 WHEN 122170 THEN 20 WHEN 125630 THEN 21 WHEN 125515 THEN 22 WHEN 124487 THEN 23 WHEN 124374 THEN 24 WHEN 124343 THEN 25 WHEN 124327 THEN 26 WHEN 126838 THEN 27 WHEN 126720 THEN 28 WHEN 126718 THEN 29 WHEN 123510 THEN 30 WHEN 122966 THEN 31 WHEN 124385 THEN 32 WHEN 122754 THEN 33 WHEN 124312 THEN 34 WHEN 122311 THEN 35 WHEN 121577 THEN 36 ELSE order END WHERE NR_DMD IN(121419,110378,124376,124163,127019,123816,124348,127017,126764,126637,122170,125630,125515,124487,124374,124343,124327,126838,126720,126718,123510,122966,124385,122754,124312,122311,121577)
22/01/2014 14:03:25 UPDATE `edited_table_name` SET `order` = CASE NR_DMD WHEN 127585 THEN 21 WHEN 124376 THEN 22 WHEN 124163 THEN 23 WHEN 127019 THEN 24 WHEN 123816 THEN 25 WHEN 124348 THEN 26 WHEN 127017 THEN 27 WHEN 126764 THEN 28 WHEN 126637 THEN 29 WHEN 122170 THEN 30 WHEN 125630 THEN 31 WHEN 125515 THEN 32 WHEN 124487 THEN 33 WHEN 124374 THEN 34 WHEN 124343 THEN 35 WHEN 124327 THEN 36 WHEN 126838 THEN 37 WHEN 126720 THEN 38 WHEN 126718 THEN 39 WHEN 123510 THEN 40 WHEN 122966 THEN 41 WHEN 124385 THEN 42 WHEN 122754 THEN 43 WHEN 124312 THEN 44 WHEN 122311 THEN 45 WHEN 121577 THEN 46 WHEN 121028 THEN 47 WHEN 123354 THEN 48 WHEN 121682 THEN 49 WHEN 120993 THEN 50 WHEN 120860 THEN 51 WHEN 120750 THEN 52 WHEN 120460 THEN 53 WHEN 120459 THEN 54 WHEN 120397 THEN 55 WHEN 119178 THEN 56 WHEN 111723 THEN 57 WHEN 127644 THEN 58 WHEN 127610 THEN 59 WHEN 127609 THEN 60 ELSE order END WHERE NR_DMD IN(127585,124376,124163,127019,123816,124348,127017,126764,126637,122170,125630,125515,124487,124374,124343,124327,126838,126720,126718,123510,122966,124385,122754,124312,122311,121577,121028,123354,121682,120993,120860,120750,120460,120459,120397,119178,111723,127644,127610,127609)
22/01/2014 14:03:25 UPDATE `edited_table_name` SET `order` = CASE NR_DMD WHEN 127638 THEN 19 WHEN 127592 THEN 20 WHEN 124376 THEN 21 WHEN 124163 THEN 22 WHEN 127019 THEN 23 WHEN 123816 THEN 24 WHEN 124348 THEN 25 WHEN 127017 THEN 26 WHEN 126764 THEN 27 WHEN 126637 THEN 28 WHEN 122170 THEN 29 WHEN 125630 THEN 30 WHEN 125515 THEN 31 WHEN 124487 THEN 32 WHEN 124374 THEN 33 WHEN 124343 THEN 34 WHEN 124327 THEN 35 WHEN 126838 THEN 36 WHEN 126720 THEN 37 WHEN 126718 THEN 38 WHEN 123510 THEN 39 WHEN 122966 THEN 40 WHEN 124385 THEN 41 WHEN 122754 THEN 42 WHEN 124312 THEN 43 WHEN 122311 THEN 44 WHEN 121577 THEN 45 WHEN 121028 THEN 46 WHEN 123354 THEN 47 WHEN 121682 THEN 48 WHEN 120993 THEN 49 WHEN 120860 THEN 50 WHEN 120750 THEN 51 WHEN 120460 THEN 52 WHEN 120459 THEN 53 WHEN 120397 THEN 54 WHEN 119178 THEN 55 WHEN 111723 THEN 56 WHEN 127644 THEN 57 ELSE order END WHERE NR_DMD IN(127638,127592,124376,124163,127019,123816,124348,127017,126764,126637,122170,125630,125515,124487,124374,124343,124327,126838,126720,126718,123510,122966,124385,122754,124312,122311,121577,121028,123354,121682,120993,120860,120750,120460,120459,120397,119178,111723,127644)
I thought MySQL would deal with the simultaneous hits on the same table. But it looks like not. Perhaps it's some issue with table locks.
If you can give me any advice in any configuration or technique or even another better way to persist the reordered list, I'd be very greateful.
Thanks,
You could try to use the following session parameters before your update statement in your servlet.
"SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED"
That would allow that if two statements occurs almost instantanously, it would take the latest one even if the other process had not commited it to the server.
For sure it is better to send changes only if the end-user did not did any drag & drop for more than X seconds (ie: 2) and send only 1 request. That would solve the problem also.
Would you consider using something in your client side code so that you don't submit multiple AJAX requests simultaneously such as setTimeout when the list is reordered.
Perhaps something like this:
http://benalman.com/code/projects/jquery-message-queuing/examples/ajax/
I would suggest that you maintain a check for a period of inactivity and when there is a good amount of inactivity, send latest update (that has the cumulative update) to the server.
During the execution of your update query InnoDB locks every row that it traverses to find the rows it is modifying. So to reduce the number of locks you can split your query into two separate queries:
Get PRIMARY_KEY_LIST, suppose that the primary key of edited_table_name is id
SELECT id FROM edited_table_name WHERE NR_DMD IN(...)
Update basing on primary key list
UPDATE edited_table_name SET order = CASE... WHERE id IN (PRIMARY_KEY_LIST)
This will reduce the number of locks because it reduces the number of rows that the engine has to traverse.
Another option is to put an index on NR_DMD columns
I might have a handler to throttle the hits that come to the servlet probably in this scenario :
Rather than instantly applying every new order request that hits the servlet , I would store the info/details in a table say new_order_requests_table .
I would have a flag which is used/updated by this handler accordingly with status of itself , say : Idle , Under Progress , etc .
Whenever the above flag shows as Idle , I would consider to apply the latest row from the new_order_requests_table and probably delete all earlier rows from it .
For multiple users , you would need to modify the above accordingly .
Further , when it is needed to update many rows in a MySQL table in a single statement , sometimes it would be better with MyISAM which does table level locking as opposed to InnoDB which does row level locking . This is because InnoDB might be consuming considerable duration just to lock and unlock those many rows .You could try switching between MyISAM and InnoDB to find the better suitable engine for this table in your application .
I think you can do the following:
CREATE TEMPORARY TABLE Table1 (
NR_DMD int NOT NULL);
INSERT INTO Table1 (NR_DMD)
VALUES
(92059),(124376),(124163),(127019),(123816),(124348),(127017),(126764),(126637),
(122170),(125630),(125515),(124487),(124374),(124343),(124327),(126838),(126720),
(126718),(123510),(122966),(124385),(122754),(124312),(122311),(121577),(121028),
(123354),(121682),(120993),(120860),(120750),(120460),(120459),(120397),(119178),
(111723),(127644),(127610),(127609),(127542),(125799);
select * from Table1
22/01/2014 14:03:25
UPDATE `edited_table_name
` SET `order` = CASE NR_DMD WHEN 92059 THEN 22 WHEN 124376 THEN 23 WHEN 124163 THEN 24
WHEN 127019 THEN 25 WHEN 123816 THEN 26 WHEN 124348 THEN 27 WHEN 127017 THEN 28
WHEN 126764 THEN 29 WHEN 126637 THEN 30 WHEN 122170 THEN 31
WHEN 125630 THEN 32 WHEN 125515 THEN 33 WHEN 124487 THEN 34
WHEN 124374 THEN 35 WHEN 124343 THEN 36 WHEN 124327 THEN 37
WHEN 126838 THEN 38 WHEN 126720 THEN 39 WHEN 126718 THEN 40
WHEN 123510 THEN 41 WHEN 122966 THEN 42 WHEN 124385 THEN 43
WHEN 122754 THEN 44 WHEN 124312 THEN 45 WHEN 122311 THEN 46
WHEN 121577 THEN 47 WHEN 121028 THEN 48 WHEN 123354 THEN 49
WHEN 121682 THEN 50 WHEN 120993 THEN 51 WHEN 120860 THEN 52
WHEN 120750 THEN 53 WHEN 120460 THEN 54 WHEN 120459 THEN 55
WHEN 120397 THEN 56 WHEN 119178 THEN 57 WHEN 111723 THEN 58
WHEN 127644 THEN 59 WHEN 127610 THEN 60 WHEN 127609 THEN 61
WHEN 127542 THEN 62 WHEN 125799 THEN 63 ELSE order END
WHERE NR_DMD IN(Select NR_DMD from Table1);
Summary:
1)Create temp table and insert the values for first update.
2)
UPDATE tablename SET ColName =CASE STATEMENT
Where NR_DMD in ( SELECT NR_DMD FROM temp table)
3) Do the same for 2 other update statement.
I think this will help you to better perform.

unknown data encoding

While I was working with an old application with existing database which is in ms-access contains some strange data encoding such as 48001700030E0F465075465A56525E1100121D04121B565A58 as email address
What kind of data encoding is this? i tried base64 but it dosent seems that. Can anybody with previous experience with ms-access could tell me what possible encoding could this be.
edit:
more samples
54001700030E0F46507546474550481C1D09090D04461B565A195E5F
40001700030E0F4650755F564E545F06025D100E0C
38001700030E0F4650754545564654155C101C0C
46001700030E0F4650755D565150591D1B0007124F565A58
above samples are surely emails and for web url it looks like this
440505045D070D54585C5B50585D581C1701004F025A58
440505045D121147544C5B584D4B5D17015D100E4F5C5B
This is vb + ms access program if that can be any help and i think it some standard encoding
edit (2) ::
from looking at web url encoding it seems 0505045D could be for http://
edit(3) ::
1 combination found
52021301161209755354595A5E5F561D170B030E1341461B56585A == paresh#falmingoexports.com
It appears to be bytes encoded as hexadecimal. But what those bytes mean, I don't know. Decoding it to ASCII doesn't reveal much:
H \x00\x17\x00\x03\x0e\x0fFPu FZVR^ \x11\x00\x12\x1d\x04\x12\x1bVZX
T \x00\x17\x00\x03\x0e\x0fFPu FGEPH \x1c\x1d\t\t\r\x04F\x1bVZ\x19^_
# \x00\x17\x00\x03\x0e\x0fFPu _VNT_ \x06\x02]\x10\x0e\x0c
8 \x00\x17\x00\x03\x0e\x0fFPu EEVFT \x15\\\x10\x1c\x0c
F \x00\x17\x00\x03\x0e\x0fFPu ]VQPY \x1d\x1b\x00\x07\x12OVZX
Things I've noticed that may help crack the code:
The 2nd to 10th bytes appear to constant \x00\x17\x00\x03\x0e\x0fFPu.
The first byte is BCD length (spotted by Daniel Brückner!)
16th bytes onwards appear to some binary format that either encode the data or perhaps a pointer to the data.
Two of them end in: \x12?VZX.
The strings seem to be hexadecimal representations of some binary data.
The first two digits are the length of the string - decimal, not hexadecimal - so not the entire string is hexadecimal.
38 001700030E0F465075 4545 5646 5415 5C10 1C0C
40 001700030E0F465075 5F56 4E54 5F06 025D 100E 0C
46 001700030E0F465075 5D56 5150 591D 1B00 0712 4F56 5A58
48 001700030E0F465075 465A 5652 5E11 0012 1D04 121B 565A 58
54 001700030E0F465075 4647 4550 481C 1D09 090D 0446 1B56 5A19 5E5F
^ ^
| |
| +---- constant part, 9 bytes, maybe mailto: or same domain name of
| reversed email addresses (com.example#foo)
|
+---- length of the reset in decimal, not hexadecimal
I can see no clear indication for the location of the at-sign and the dot before the top-level domain. Seems to be an indication against simple mono-alphabetic substitutions like ROT13.
paresh#falmingoexports.com
Length
26 characters
Histogram
1x
h # f l i n g x t . c
3x o
2x p 2x a 2x m 2x r 2x e 2x s
ASCII values in hexadecimal representation
70 61 72 65 73 68 40 66 61 6C
6D 69 6E 67 6F 65 78 70 6F 72
74 73 2E 63 6F 6D
The length of 52 hexadecimal symbols matches length of the
encoded string.
52 02 13 01 16 12 09 75 53 54 59
5A 5E 5F 56 1D 17 0B 03 0E 13
41 46 1B 56 58 5A
Histogram
1x
01 02 03 09 0B 0E 12 16 17 1B
1D 41 46 53 54 58 59 5E 5F 75
2x 13 2x 56 2x 5A
The histograms don't match - so this rules out mono-alphabetic substitutions possibly followed by a permutation of the string.