|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I'm wondering how it will work in 32/64?
I mean at compile time, where you don't know what the target machine runs on.
|
|
|
|
|
I have some information about the target machine like endianness and word size. If I don't support the platform you can fill in the information with -D defines.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I should add, this routinely runs on 32-bit machines. This code is now running on a 64-bit machine.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Does 32 not run in 64?
The other way around I know that is not possible / so easy, but I thought 32 would not be a big deal in 64
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
You're thinking of the x86 platform. That might not apply to microcontrollers or SBCs.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
true 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I have a need to write a small SQL parser and try to look for an example.
my SQL parser is very minimal: just need to extract all field names and tables that are used this SQL statements.
any good example to recommend?
my business need is to extract all field names and database names associated with these fields:
select a.var1,
a.var2,
b.var3,
b.var4
from db1 a left join db2 b
on a.var5=b.var5
;
my need is to put these vars into this form in Excel workbook:
db1 var1
db1 var2
db2 var3
db2 var4
thanks a million!
diligent hands rule....
modified 16-Sep-23 15:04pm.
|
|
|
|
|
GoldParser has a SQL Grammar for it. You might use that. Just google GoldParser. It's for .NET and I think old VB
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
diligent hands rule....
|
|
|
|
|
For what purpose? What are you trying to do? It sounds like a bad idea.
|
|
|
|
|
my business need is to extract all field names and database names associated with these fields:
select a.var1,
a.var2,
b.var3,
b.var4
from db1 a left join db2 b
on a.var5=b.var5
;
my need is to put these vars into this form in Excel workbook:
db1 var1
db1 var2
db2 var3
db2 var4
diligent hands rule....
modified 16-Sep-23 15:03pm.
|
|
|
|
|
It's not something I would want to tackle. I suppose that handling the basics like you show could be doable, but things like subqueries and CTEs would be problematic.
Do you think you'll need to support things like
SELECT X + Y AS Z ... ?
And which flavor of SQL? PL/SQL, T-SQL, etc.
|
|
|
|
|
Probably something that I would enjoy doing but not sure I would attempt to say it was "small".
I agree with your examples.
Not to mention is the SQL only going to come from SQL scripts? Or also from other code bases.
|
|
|
|
|
|
thanks for the link. I prefer SQL datatable one.
diligent hands rule....
|
|
|
|
|
A good example no, sorry.
But next question I recommend you to write it in the proper section 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I just look for some thoughts here, not a specific language implementation.
I may need to implement my request by other scripting languages such as SAS.
diligent hands rule....
|
|
|
|
|
Sorry, for me looks like a question. Not a question about code, but a still a programming question.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Southmountain wrote: I may need to implement my request by other scripting languages such as SAS.
Huh?
You want to try to implement a SQL Parser using 'SAS' (whatever that is)?
Seems like a bad idea to me.
I have written interpreters. And one compiler.
I have been using Perl for 40 years and I have parsed SQL using that before. Multiple times.
I have also taken a class on compiler theory so I do know what goes into a parser.
And in my estimation with your general description you are setting yourself up for failure. Or for writing a lot more code than you expect.
Thing that can impact the actual project
1. How structured is the SQL? For example if this is dumped from a SQL database tool the form is exact, but if it is human created files then the form will be all over the place.
2. How much SQL exists? 1,000 lines? 10,000? 1 million? The more lines the more likely variations will exist.
3. How often will this need to happen. Every day? Every day for each customer? Only one time and never again?
Consider the following case
1. You are parsing some SQL script files. By that I mean that there is nothing in those files except SQL.
2. Those script files are in use. So you know absolutely that the SQL is valid.
3. This is one time project
4. The number of files are low (total number of lines are probably less than 10,000)
6. You can add a manual step in the process to deal with the more complex examples.
Given the above, and that I really know how to do the above in Perl, this would be a fairly easy project for me.
I however would NOT attempt to do it in Python. Because I have never used Python.
I would not choose to do it in C# nor Java even though I know those languages very well because I know that Perl is going to be better at doing the real work that is needed.
If the project was much bigger than what I suggested above then I would look at making a real parser. Probably in C# or Java. C++ is an option but since it has been so long since I used that I would prefer one of the others. I would do that even though I has been a long time since I made a real parser (versus just munging a solution.) But that is going to become a problem if I could not find an actual BNF type description of the SQL being targeted. There is no way I would attempt to write my own BNF for any of the major databases without vastly increasing the timeline for the work. (And I have written a BNF before and read others.)
Note also that if there are different types of SQL then one needs a parser for each regardless of how one implements it.
|
|
|
|
|
Quote: You are parsing some SQL script files. By that I mean that 1. there is nothing in those files except SQL.
2. Those script files are in use. So you know absolutely that the SQL is valid.
3. This is one time project
4. The number of files are low (total number of lines are probably less than 10,000)
6. You can add a manual step in the process to deal with the more complex examples.
yes, my case meets all of above points. thanks for your info!
most cases, my SQL line count will be less than 500.
I figured out that my path will be: table driven LL(1) syntax directed parsing.
SAS can do table easily. also I figured out how to implement stack and queue today.
So it is very hopeful to me.
diligent hands rule....
|
|
|
|
|
Southmountain wrote: most cases, my SQL line count will be less than 500.
Note that I said total line count. The more sources there are the more chance for variability which will break any hack.
Southmountain wrote: table driven LL(1) syntax directed parsing.
To do formal parsing you need a formal SQL language definition.
Also been a while but seems that I recall that these days languages might require adjustments (manual) in the parser code to deal with variations that formal language definitions were never designed to describe. But I might not be recalling that correctly. So although the formal spec for SQL itself is fairly simple you are unlikely to be dealing with SQL but rather PL/SQL, TSQL, etc.
|
|
|
|
|
My case is Teradata SQL.
thanks for the great info!![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
diligent hands rule....
|
|
|
|
|
Southmountain wrote: Teradata SQL.
I could not find a BNF for that.
In contrast and for comparison it was rather easy to find one for TSQL.
|
|
|
|
|
I think my need is not a full bloom SQL parser, I just need to get all field names. So I plan to manually craft a parser to fit my situation.
diligent hands rule....
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
