473,847 Members | 1,558 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Recursive join - blind alley?

Regular viewers may want to turn off now.

This will be an orchestral management system. Musicians and other staff
being booked/paid for jobs.

A job may contain other jobs, e.g:

World Tour contains
US leg and Europe leg (and others)
US leg contains State tours (and others)
New Jersey tour contains Hoboken concert (and others)
Hoboken concert contains dress rehearsal, 1st show, 2nd show

Or a job may be single:

My band plays at Simon Foreman's barmitzvah

To account for the variability I imagined a recursive join. I've done a fair
bit of research. Which frequently brings up the words 'Joe Celko' and 'BOM'.
I'm not sure that the BOM is exactly what I need, but it's close. I actually
think an adjacency list is a better solution in this case than nested sets,
though probably implemented with (at least) 2 tables. This area may or may
not be the problem. As a matter of fact the same problems would arise, I
think, with a static structure, e.g:
Production-<Events

In the 'real world', the person I'm doing this for, a musician may be booked
for a show, will need to be booked for some/all of the events in that show,
but may be paid at the show level. i.e. they are booked for 7 shows, but are
paid a total of $548.34 for all shows together. Involved at a 'child' level
but paid at a 'parent' level. Here there seems to be duplication, we KNOW
they are involved with the parent if they are involved with any of the
children, and so on all the way up the hierachy.

Some people may be involved with a parent but NOT it's children. An arranger
writes the orchestrations for a week long show, but doesn't turn up on the
shows. So there is no certainty that people can only be involved at the
lowest child level.

But if on some occasions people are involved at a child level and no parent
level (paid by the individual show) whereas on others they are involved with
both (booked for the gigs, paid by the week) there's a difference, sometimes
there are duplicate data, sometimes there aren't.

OK, if it's just payment that's the problem, spin if off into 2 junction
tables:

Event -<Fee>-Musician

Event-<Booked>-Musician

That separates the two things that are getting muddled. But this now looks
strange. People are now getting paid for jobs they might not be involved in.
How so? It would actually accomodate copyright payments and suchlike (which
aren't part of the requirements) but it still looks strange. And I suspect
complex to implement.

I realise this isn't the first time I've asked for help on this, but I have
done a huge amount of pondering/studying and am asking for help because I
think I may have thought myself into a corner. Another perspective would be
valued.

TIA, Mike MacSween



Nov 12 '05 #1
25 2842
"Mike MacSween" <mi************ ******@btintern et.com> wrote in message
news:3f******** *************** @news.aaisp.net .uk...
Regular viewers may want to turn off now.

This will be an orchestral management system. Musicians and other staff
being booked/paid for jobs.

A job may contain other jobs, e.g:

World Tour contains
US leg and Europe leg (and others)
US leg contains State tours (and others)
New Jersey tour contains Hoboken concert (and others)
Hoboken concert contains dress rehearsal, 1st show, 2nd show

Or a job may be single:

My band plays at Simon Foreman's barmitzvah

To account for the variability I imagined a recursive join. I've done a fair bit of research. Which frequently brings up the words 'Joe Celko' and 'BOM'. I'm not sure that the BOM is exactly what I need, but it's close. I actually think an adjacency list is a better solution in this case than nested sets, though probably implemented with (at least) 2 tables. This area may or may
not be the problem. As a matter of fact the same problems would arise, I
think, with a static structure, e.g:
Production-<Events

In the 'real world', the person I'm doing this for, a musician may be booked for a show, will need to be booked for some/all of the events in that show, but may be paid at the show level. i.e. they are booked for 7 shows, but are paid a total of $548.34 for all shows together. Involved at a 'child' level but paid at a 'parent' level. Here there seems to be duplication, we KNOW
they are involved with the parent if they are involved with any of the
children, and so on all the way up the hierachy.

Some people may be involved with a parent but NOT it's children. An arranger writes the orchestrations for a week long show, but doesn't turn up on the
shows. So there is no certainty that people can only be involved at the
lowest child level.

But if on some occasions people are involved at a child level and no parent level (paid by the individual show) whereas on others they are involved with both (booked for the gigs, paid by the week) there's a difference, sometimes there are duplicate data, sometimes there aren't.

OK, if it's just payment that's the problem, spin if off into 2 junction
tables:

Event -<Fee>-Musician

Event-<Booked>-Musician

That separates the two things that are getting muddled. But this now looks
strange. People are now getting paid for jobs they might not be involved in. How so? It would actually accomodate copyright payments and suchlike (which aren't part of the requirements) but it still looks strange. And I suspect
complex to implement.

I realise this isn't the first time I've asked for help on this, but I have done a huge amount of pondering/studying and am asking for help because I
think I may have thought myself into a corner. Another perspective would be valued.

TIA, Mike MacSween


If you're looking for another perspective - here's a different direction to
consider:

Do not rely on the table structure to provide the information you require -
use a system of product codes and masking instead.

Here are some product codes you might use:

WT2004-XX-XX-XX-000 World Tour 2004
WT2004-US-XX-XX-000 US leg of 2004 World Tour
WT2004-US-NJ-HB-000 Hoboken Concert
WT2004-US-NJ-HB-001 Hoboken Concert - Dress rehearsal
WT2004-US-NJ-HB-002 Hoboken Concert - Show 1
WT2004-US-NJ-HB-003 Hoboken Concert - Show 2
WT2004-US-NJ-HB-101 Hoboken Concert - All shows incl. rehearsal

WT2004-EU-GE-XX-000 Germany
WT2004-EU-GE-HD-000 Heidelberg Concert
WT2004-EU-GE-HD-003 Heidelberg Concert - Show 2

This system allows you to code the products so you can retrieve the detail
you need. For example, find all the payments for the 2004 world tour - you
just need WHERE ProductCode LIKE "WT2004*" or perhaps you need all years,
all concerts in Germany - WHERE ProductCode LIKE "??????-EU-GE-??-???"

I think you just need to accept there some things are too complicated to be
handled by table structure alone and some form of meaningful analysis codes
are needed. If you consider how a large supermarket might handle, say, a
specially priced multi-pack of fruit juice. For pricing reasons, they need
a unique product code with a price, but for other reasons they may need to
know that they sold a pack with a total volume of 4 litres. The coding of
the product will let them analyse how much apple juice, orange juice, all
juices, how many multi-packs etc have been sold but no use will be made of
relational structures (eg you would not need tblMultiPack and tblItem).

I hope you are able to take this idea and apply it to your database - it
should make certain aspects a million times easier, more flexible and more
in line with how products are traditionally categorized.

</MyTuppenceWorth >

Fletcher
Nov 12 '05 #2
"Fletcher Arnold" <fl****@home.co m> wrote in message
news:bt******** *@hercules.btin ternet.com...
WT2004-XX-XX-XX-000 World Tour 2004
WT2004-US-XX-XX-000 US leg of 2004 World Tour
WT2004-US-NJ-HB-000 Hoboken Concert
WT2004-US-NJ-HB-001 Hoboken Concert - Dress rehearsal
WT2004-US-NJ-HB-002 Hoboken Concert - Show 1
WT2004-US-NJ-HB-003 Hoboken Concert - Show 2
WT2004-US-NJ-HB-101 Hoboken Concert - All shows incl. rehearsal

WT2004-EU-GE-XX-000 Germany
WT2004-EU-GE-HD-000 Heidelberg Concert
WT2004-EU-GE-HD-003 Heidelberg Concert - Show 2
Wouldn't
WT2004 World Tour 2004
WT2004-US US leg of 2004 World Tour
WT2004-US-NJ-HB Hoboken Concert
WT2004-US-NJ-HB-001 Hoboken Concert - Dress rehearsal


be more natural representation?
Nov 12 '05 #3
Fletcher and Mikito

Thanks. Good ideas, but I'm pushing this forward. I know what you mean about
table structure not always doing the whole job. But sometimes thinking aloud
like this gets me forward.

I think the recursive join/BOM may be the way. Forget payments. If a
musician is 'booked' for an 'element' (at last, I've found the right word)
of a production, then they are ipso facto 'booked' for that elements parent,
grandparent etc. So the idea that a musician can't be booked for Tuesday's
show (child element) and for the week's run of the show (parent element)
makes sense. We know they're booked for part/all of the week's run if
they're booked for the Tuesday (+Wednesday etc.). As a matter of fact Joe
Celko's nested sets might very well be a better solution here, as it looks
easier to drill up/down the structure using standard SQL. There might be
some quite complex triggers to write to enforce this though. Time will tell,
but it's a worry at the back of my mind. A common 'use case' is the client
books musicians for, let's say, a weeks run of a show before she has the
details. e.g. - 'Mike, can I book you for Annie 15-22 of November, it'll be
about £400 for the week but I haven't got the details yet'. In my scenario
when the dates are known she (or the system) will have to unbook me for the
week's run (which is now a parent element) and book me for each date. It
might be easy or not.

But the payments is easier (at least at an ER model) that I thought. I
simply group a set of 'musician booked for element' together into a payment
group. So people may get paid at the 'parent' level, but only
coincidentally. Other times the payment group may be completely unrelated to
the element/sub-element structure. For instance a month long show,
consisting of 4 single week runs, each consisting of 7 shows. That's the BOM
type structure. But the trumpet player can't make any of the Tuesday shows.
So she puts a 'dep' in. The dep's 4 tuesdays fees are 'grouped' into one
payment. My mistake was that I was equating payments with the organisational
structure of the thing.

I need to investigate this a lot further of course. My experience of finding
an 'ideal' schema is that the implementation becomes a nightmare,
un-updateable queries and so on. Or difficult deletions.

Yours comments, as always, most welcome.

Yours, Mike MacSween

"Fletcher Arnold" <fl****@home.co m> wrote in message
news:bt******** *@hercules.btin ternet.com...
"Mike MacSween" <mi************ ******@btintern et.com> wrote in message
news:3f******** *************** @news.aaisp.net .uk...
Regular viewers may want to turn off now.

This will be an orchestral management system. Musicians and other staff
being booked/paid for jobs.

A job may contain other jobs, e.g:

World Tour contains
US leg and Europe leg (and others)
US leg contains State tours (and others)
New Jersey tour contains Hoboken concert (and others)
Hoboken concert contains dress rehearsal, 1st show, 2nd show

Or a job may be single:

My band plays at Simon Foreman's barmitzvah

To account for the variability I imagined a recursive join. I've done a fair
bit of research. Which frequently brings up the words 'Joe Celko' and

'BOM'.
I'm not sure that the BOM is exactly what I need, but it's close. I

actually
think an adjacency list is a better solution in this case than nested

sets,
though probably implemented with (at least) 2 tables. This area may or may not be the problem. As a matter of fact the same problems would arise, I
think, with a static structure, e.g:
Production-<Events

In the 'real world', the person I'm doing this for, a musician may be

booked
for a show, will need to be booked for some/all of the events in that

show,
but may be paid at the show level. i.e. they are booked for 7 shows, but

are
paid a total of $548.34 for all shows together. Involved at a 'child'

level
but paid at a 'parent' level. Here there seems to be duplication, we KNOW they are involved with the parent if they are involved with any of the
children, and so on all the way up the hierachy.

Some people may be involved with a parent but NOT it's children. An

arranger
writes the orchestrations for a week long show, but doesn't turn up on the shows. So there is no certainty that people can only be involved at the
lowest child level.

But if on some occasions people are involved at a child level and no

parent
level (paid by the individual show) whereas on others they are involved

with
both (booked for the gigs, paid by the week) there's a difference,

sometimes
there are duplicate data, sometimes there aren't.

OK, if it's just payment that's the problem, spin if off into 2 junction
tables:

Event -<Fee>-Musician

Event-<Booked>-Musician

That separates the two things that are getting muddled. But this now looks strange. People are now getting paid for jobs they might not be involved

in.
How so? It would actually accomodate copyright payments and suchlike

(which
aren't part of the requirements) but it still looks strange. And I suspect complex to implement.

I realise this isn't the first time I've asked for help on this, but I

have
done a huge amount of pondering/studying and am asking for help because I think I may have thought myself into a corner. Another perspective would

be
valued.

TIA, Mike MacSween


If you're looking for another perspective - here's a different direction

to consider:

Do not rely on the table structure to provide the information you require - use a system of product codes and masking instead.

Here are some product codes you might use:

WT2004-XX-XX-XX-000 World Tour 2004
WT2004-US-XX-XX-000 US leg of 2004 World Tour
WT2004-US-NJ-HB-000 Hoboken Concert
WT2004-US-NJ-HB-001 Hoboken Concert - Dress rehearsal
WT2004-US-NJ-HB-002 Hoboken Concert - Show 1
WT2004-US-NJ-HB-003 Hoboken Concert - Show 2
WT2004-US-NJ-HB-101 Hoboken Concert - All shows incl. rehearsal

WT2004-EU-GE-XX-000 Germany
WT2004-EU-GE-HD-000 Heidelberg Concert
WT2004-EU-GE-HD-003 Heidelberg Concert - Show 2

This system allows you to code the products so you can retrieve the detail
you need. For example, find all the payments for the 2004 world tour - you just need WHERE ProductCode LIKE "WT2004*" or perhaps you need all years,
all concerts in Germany - WHERE ProductCode LIKE "??????-EU-GE-??-???"

I think you just need to accept there some things are too complicated to be handled by table structure alone and some form of meaningful analysis codes are needed. If you consider how a large supermarket might handle, say, a
specially priced multi-pack of fruit juice. For pricing reasons, they need a unique product code with a price, but for other reasons they may need to
know that they sold a pack with a total volume of 4 litres. The coding of
the product will let them analyse how much apple juice, orange juice, all
juices, how many multi-packs etc have been sold but no use will be made of
relational structures (eg you would not need tblMultiPack and tblItem).

I hope you are able to take this idea and apply it to your database - it
should make certain aspects a million times easier, more flexible and more
in line with how products are traditionally categorized.

</MyTuppenceWorth >

Fletcher

Nov 12 '05 #4
OK, still going at it and testing my ideas in public.

Seems to me that in the 'Element' table what's required is a 'Level' field.
1 being the top, 10 (for instance) being the bottom. With a few validation
rules. An element at level 1 can't have a parent, at level 10 can't have a
child. A child must have a level that is parent level+1.

That imposes a few restrictions. Children can't have more than one parent.
That's a requirements issue, I'm awaiting a response from the client. There
can't be more than 10 levels. Although the structure of the recursively
joined table _theoretically_ allows infinite levels, in this app that won't
be the case. It's perfectly possible to imagine saying to this client, or
the similar clients its aimed at 'look, you can't have a structure more than
10 levels deep'. Or 5 or 20. It would be in that range. Whereas with a
complex BOM there might be a far taller tree. The important thing in this
app is that it is variable. From a single event to 10 nested sub events.

The level number might make a lot of SQL easier. You'd know how many sub
queries to search from top to bottom, if the bottom was at level 4, for
instance. I'm guessing.

Actually I don't thing the nested sets BOM does it. It just models _one_
thing. That's not what I want. I need more than one root node.

Yours, Mike MacSween
Nov 12 '05 #5

"Mike MacSween" <mi************ ******@btintern et.com> wrote in message
news:3f******** *************** @news.aaisp.net .uk...
OK, still going at it and testing my ideas in public.

Seems to me that in the 'Element' table what's required is a 'Level' field. 1 being the top, 10 (for instance) being the bottom. With a few validation
rules. An element at level 1 can't have a parent, at level 10 can't have a
child. A child must have a level that is parent level+1.

That imposes a few restrictions. Children can't have more than one parent.
That's a requirements issue, I'm awaiting a response from the client. There can't be more than 10 levels. Although the structure of the recursively
joined table _theoretically_ allows infinite levels, in this app that won't be the case. It's perfectly possible to imagine saying to this client, or
the similar clients its aimed at 'look, you can't have a structure more than 10 levels deep'. Or 5 or 20. It would be in that range. Whereas with a
complex BOM there might be a far taller tree. The important thing in this
app is that it is variable. From a single event to 10 nested sub events.

The level number might make a lot of SQL easier. You'd know how many sub
queries to search from top to bottom, if the bottom was at level 4, for
instance. I'm guessing.

Actually I don't thing the nested sets BOM does it. It just models _one_
thing. That's not what I want. I need more than one root node.

Yours, Mike MacSween


Well it won't take you long to design a table of elements: ElementID,
ElementName, ParentID, etc with each element having a parent in the table.
But before you go too far finalising the structure - consider the basic
issues of getting the data into the database and extracting it later. For
example, how does the user create a new production with different elements
and then link musicians and others to these elements? What will a print-out
look like? Do you intend to make use of some form of activex tree-control
or do you have another way to show this hierarchy on a piece of A4 paper?

I personally think that unless you have had a lot of experience with product
codes and fully appreciate the benefits of masking techniques with analysis
codes, then you should further investigate this before dismissing it. There
is a genuine reason why so many databases use this method - even if you use
a treeview control, even if your elements table has a parentID column, even
if you hide this code from the user and use VBA to build it up. Using
masking provides an extremely fast and efficient way to work with this sort
of data.

Alternatively, quickly build the elements table (the proposed design is
pretty straight forward) and then try to construct a couple of key forms and
reports around it. Let us know how you get on.

Fletcher
Nov 12 '05 #6
Fletcher

Thanks. I wasn't dismissing your codes out of hand. I appreciate the advice.
As a matter of fact right now I'm looking at materialised paths. This
http://fungus.teststation.com/~jon/t...eeHandling.htm in
particular looks interesting. But I repeat I've only just come across this.
Though your codes look a little bit like materialised paths (and that's a
very top of the head comment!).

Yes, I usually work the way you suggest. Come up with a fairly abstract
ER/CDM model (or one corner of it). Then quickly knock up some nonsense
tables in Access to see if/how well it works. Missing out the weeks of
correct relational modelling and such.

Cheers, Mike
Nov 12 '05 #7
nested sets do allow for multiple root nodes.. ie trees
if used it to create a small mdb per a 'communication' thread posted
here last week - I can send you a copy if you wish ?

"Mike MacSween" <mi************ ******@btintern et.com> wrote in message news:<3f******* *************** *@news.aaisp.ne t.uk>...
OK, still going at it and testing my ideas in public.

Seems to me that in the 'Element' table what's required is a 'Level' field.
1 being the top, 10 (for instance) being the bottom. With a few validation
rules. An element at level 1 can't have a parent, at level 10 can't have a
child. A child must have a level that is parent level+1.

That imposes a few restrictions. Children can't have more than one parent.
That's a requirements issue, I'm awaiting a response from the client. There
can't be more than 10 levels. Although the structure of the recursively
joined table _theoretically_ allows infinite levels, in this app that won't
be the case. It's perfectly possible to imagine saying to this client, or
the similar clients its aimed at 'look, you can't have a structure more than
10 levels deep'. Or 5 or 20. It would be in that range. Whereas with a
complex BOM there might be a far taller tree. The important thing in this
app is that it is variable. From a single event to 10 nested sub events.

The level number might make a lot of SQL easier. You'd know how many sub
queries to search from top to bottom, if the bottom was at level 4, for
instance. I'm guessing.

Actually I don't thing the nested sets BOM does it. It just models _one_
thing. That's not what I want. I need more than one root node.

Yours, Mike MacSween

Nov 12 '05 #8
>> I've done a fair bit of research. Which frequently brings up the
words 'Joe Celko' and 'BOM'. <<

Now I am obligated to provide a nested sets solution! Let me be
sloppy and not put on all of the constraints for a tree:

CREATE TABLE Events
(event_name VARCHAR(35) NOT NULL,
performance_nbr INTEGER NOT NULL, -- or date?
performer_id INTEGER NOT NULL
REFERENCES Performers (performer_id)
ON UPDATE CASCADE,
fee DECIMAL(14,4) NOT NULL CHECK (fee >= 0.00),
lft INTEGER NOT NULL UNIQUE CHECK (lft > 0),
rgt INTEGER NOT NULL UNIQUE,
CHECK (lft < rgt),
PRIMARY KEY (event_name, performance_nbr , performer_id)
);

When you put in a node, put it in at the appropriate level in the
tree. An arranger shows up at the highest event level for all
performances (do they get paid by performance or by show? I don't know
this trade). A nose flute player shows up at the lowest levels like
"Elvis-2004 Tour; jail house rock number" and performances 1,2,3 and
7.

Now the regular hierarchical summations will work.
Nov 12 '05 #9
"Roger" <le*********@na tpro.com> wrote in message
news:8c******** *************** ***@posting.goo gle.com...
nested sets do allow for multiple root nodes.. ie trees
if used it to create a small mdb per a 'communication' thread posted
here last week - I can send you a copy if you wish ?


Yes please. What constitutes 'small'? I've cross posted here, can you
remember which NG and the subject line?

Yours, Mike MacSween
Nov 12 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
3435
by: Oxmard | last post by:
Armed with my new O'Reilly book Optimizing Oracle Performance I have been trying to get a better understanding of how Oracle works. The book makes the statement, " A database cal with dep=n + 1 is the recursive child of the first subsequent dep=n database call listed in the SQL data stream. The book gives a few examples, and in trying it out it seemed to work until I tried the following SQL. My question are why does this not keep with...
4
9277
by: Rodusa | last post by:
I am having problem to apply updates into this function below. I tried using cursor for updates, etc. but no success. Sql server keeps telling me that I cannot execute insert or update from inside a function and it gives me an option that I could write an extended stored procedure, but I don't have a clue of how to do it. To quickly fix the problem the only solution left in my case is to convert this recursive function into one recursive...
4
2435
by: Nicolas Vigier | last post by:
Hello, I have in my python script a function that look like this : def my_function(arg1, arg2, opt1=0, opt2=1, opt3=42): if type(arg1) is ListType: for a in arg1: my_function(a, arg2, opt1=opt1, opt2=opt2, opt3=opt3) return if type(arg2) is ListType:
20
18910
by: Gary Manigian | last post by:
I have 2 tables, one-to-many, that contain bills of material(BOMs): tblBOM: lngBOMID (PK) strAssemblyPartNo strDescription tblBOMDetail: lngBOMDetailID (PK) lngBOMID (FK)
5
5042
by: purushneel | last post by:
Hi, I work primarily on Oracle databases. I am trying to convert a recursive stored procedure written in Oracle to DB2. Does DB2 UDB v8.2 (Windows/AIX) supports recursive stored procedures ?? After some research, I found out that to call recursively in DB2, the stored procedure should be CALLed using dynamic SQL. I am not sure whether it is the right way. Am I missing something ?? Please let me know...
13
3503
by: Pelmen | last post by:
How can I get rid of recursive call __getattr__ inside this method, if i need to use method or property of the class?
0
1963
by: champ1979 | last post by:
I wrote an algorithm to get all the relatives of a person in a family tree. I'm basically getting all the users from the DB and am doing the recursive logic in code, so that there is only 1 call made to the DB. However, I am trying to do the same thing within a stored procedure in SQL using recursive CTEs (I think the performance might be better) but I'm finding it really tough to craft the CTE. I would really appreciate if someone could...
2
2407
by: sebastien.abeille | last post by:
Hello, I would like to create a minimalist file browser using pyGTK. Having read lot of tutorials, it seems to me that that in my case, the best solution is to have a gtk.TreeStore containing all the files and folders so that it would map the file system hierarchy.
2
3024
by: Martin Marcher | last post by:
Hello, I'm playing around with os.walk and I made up del_tree(path) which I think is correct (in terms of the algorithm, but not as python wants it :)). As soon as some directory is deleted the iterator of os.walk chokes. OK that is somehow clear to me as it can't be valid anymore since it can't go to the just deleted directory but it is in the iterator.
0
9735
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10658
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10347
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9497
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7889
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7062
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5730
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5915
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4133
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.