ADO.NET

Απ: Dynamic SQL generation is not supported against multiple base tables

KelMan — Mon, 15 Oct 2007 15:57:30 GMT

Ορίστε... Λείπεις το ΣΚ και χάνεις τις καλές συζητήσεις...

Thiseas:
Η αλήθεια όμως είναι οτι εξακολουθώ να μην βρίσκω άμεση σύνδεση με το πρόβλημα που έχω τώρα....
Είναι, ας πούμε, μια προτροπή να αλλάξω τρόπο υλοποίησης? Πες οτι αυτό δεν γίνεται...

Έχεις διάφορες λύσεις. Από αυτή που προτείνει στο άρθρο του ο William Vaugn μέχρι να χρησιμοποιήσεις ένα ORM και να μην ασχοληθείς καθόλου (ίσως λίγο) με τον data access κώδικα. Στο ενδιάμεσο, αν επιμένεις να δουλέψεις με DataSets, τότε εδώ και πάλι έχεις λύσεις. Ίσως να μπορείς να χρησιμοποιήσεις updatable views αν αυτό που ζητάς είναι σε ένα DataTable να βλέπεις lookup πεδία από τα master tables. Ωστόσο, δεν βλέπω τον λόγο να μην δουλέψεις με ξεχωριστά DataTables τα οποία θα έχουν DataRelations μεταξύ τους.

Thiseas:
Θα μου επιτρέψεις να διαφωνήσω εδώ....
Η Borland το έχει υλοποιήσει αυτό στα client-datasets που λειτουργούν σε disconnected mode και μπορεί και η MS κάλιστα να το κάνει... (νομίζω)...

Φεύ... Έχω να δουλέψω με Delphi από την εποχή της έκδοσης 3...

Απ: Dynamic SQL generation is not supported against multiple base tables

cap — Fri, 12 Oct 2007 23:55:27 GMT

Γκουχ, η αλήθεια είναι οτι ίσως έφυγα λίγο off-topic. Δεν το σύνδεσα με το αρχικό θέμα, απλά προσπάθησα να εξηγήσω τι σημαίνει disconnected model γιατί είδα οτι ενδέχετο να υπάρχει παρανόηση.

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 23:53:47 GMT

Κατανοητό και αποδεκτό Σωτήρη... (βλέπε clientdatasets πιο πάνω)... και όντως διαφορετικό από το Isolation και State.
Μιλήσαμε!

Η αλήθεια όμως είναι οτι εξακολουθώ να μην βρίσκω άμεση σύνδεση με το πρόβλημα που έχω τώρα....
Είναι, ας πούμε, μια προτροπή να αλλάξω τρόπο υλοποίησης? Πες οτι αυτό δεν γίνεται...

KelMan:
Επιπρόσθετα, να σου πω Thiseas ότι αυτό που περιγράφεις, υποστηρίζεται από το engine της Borland (αλλά και από το παλιό ADO της Microsoft) για έναν και μόνο λόγο. Αυτά τα engines δουλεύουν σε connected mode.....

Θα μου επιτρέψεις να διαφωνήσω εδώ....
Η Borland το έχει υλοποιήσει αυτό στα client-datasets που λειτουργούν σε disconnected mode και μπορεί και η MS κάλιστα να το κάνει... (νομίζω)...

Απ: Dynamic SQL generation is not supported against multiple base tables

cap — Fri, 12 Oct 2007 23:37:57 GMT

Η παράθεσή σου έρχεται από document για το Mono και ο συγγραφέας μιλάει για "mode" κάπως αυθαίρετα. Εγώ μιλάω για το disconnected model.

Από το Intro to Datasets (MSDN): http://msdn2.microsoft.com/en-us/library/8bw9ksd6(vs.80).aspx

Datasets are objects that contain data tables where you can temporarily store the data for use in your application. If your application requires working with data, you can load the data into a dataset, which provides your application with a local in-memory cache of the data to work with. You can work with the data in a dataset even if your application becomes disconnected from the database. The dataset maintains information about changes to its data so updates can be tracked and sent back to the database when your application becomes reconnected.

Και πιό ξεκάθαρο είναι στο αντίστοιχο document για το .NET 1.1: http://msdn2.microsoft.com/en-us/library/8bw9ksd6(vs.71).aspx

Datasets store data in a disconnected cache. The structure of a dataset is similar to that of a relational database; it exposes a hierarchical object model of tables, rows, and columns. In addition, it contains constraints and relationships defined for the dataset.

Το disconnected modeL πρεσβεύει ακριβώς αυτό: Παρε τα data σου, ρίξε το connection και όταν ξανασυνδεθείς βλέπουμε. Ολα τα υπόλοιπα που αναφέρεις απευθύνονται σε άλλα aspects. Φυσικά δεν χρειάζεται να πω οτι ό,τι αναφέρεται σαν "connected mode" στο document για το mono ακολουθεί στην πραγματικότητα το disconnected model, γι'αυτό και μου τράβηξε την προσοχή!

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 23:20:33 GMT

Α!!
Μήπως εννοείτε αυτό?: http://www.mono-project.com/Writing_Connected_Mode_Testcases

Αν εννοείτε τον εσωτερικό διαχωρισμό των modes των κλάσεων του ADO.NET
...τότε φοβάμαι οτι έχουμε ξεφύγει από το αρχικό post και δεν μιλάμε για το ίδιο θέμα... μιας και δεν μιλάω καν για in-memory data processing (που αφορούν το dissconected mode)...

Επίσης πρέπει να πω οτι το ADO.NET δεν "λειτουργεί" μόνο σε Disconnected Mode.... Πως θα μπορούσε άλλοστε...
Το Dataset λειτουργεί μόνο σε Connected State Mode.... και είναι αυτό που χρησιμοποιώ στο παράδειγμα μου...

Παράθεση:

ADO.NET:
Few of the classes which constitute the connected mode behavior are given below.

DataSet
DataTable
DataRow
DataColumn
DataRelation
DataView
DataAdapter

The disconnected mode behavior is provided by the specific provider classes derived from the following common base classes.

Connection
Command
DataReader

Απ: Dynamic SQL generation is not supported against multiple base tables

cap — Fri, 12 Oct 2007 22:01:19 GMT

Αλλο πράγμα το isolation mode και άλλο το connected/disconnected model (και όχι mode).

Αυτό που πρεσβεύει το disconnected model είναι το εξής: Συνδέομαι - κάνω τη δουλειά μου - αποσυνδέομαι. Ετσι λοιπον για να δω π.χ. μια καρτέλα ενός πελάτη και για να τροποποιήσω κάτι σε αυτή γίνονται οι εξής κινήσεις:

1. Συνδέομαι-τραβάω δεδομένα-αποσυνδέομαι.

2. Εμφανίζεται η καρτέλα του πελάτη, κάνω τις αλλαγές μου, και πατάω οκ.

3. Συνδέομαι-καταχωρώ τα δεδομένα-αποσυνδέομαι.

Καθ'όλη τη διάρκεια του (2) δεν γνωρίζω τι άλλο έχει γινει σε αυτό το συγκεκριμένο πελάτη και από ποιόν, ούτε καν αν έχει η δεν έχει γίνει κάτι. Ο συγκεκριμένος πελάτης μπορεί μέχρι και να έχει διαγραφεί! Επισης το "συνδέομαι" και "αποσυνδέομαι" είναι εσωτερικές διεργασίες του μοντέλου και δεν έχει να κάνει με το αν εμείς έχουμε reference σε κάποιο connection.

Ετσι λοιπόν αποκτά άλλο νόημα ο όρος "conflict resolution" στα πλαίσια αυτού του μοντέλου. Το connected μοντέλο, αντίστοιχα, θα βρισκόταν συνδεδεμένο καθ'όλη τη διάρκεια της διεργασίας, έτσι θα μπορούσε πολύ ευκολότερα να καταλάβει τι έχει γίνει όση ώρα εμείς βρισκόμασταν στο βήμα (2).

Μανο διόρθωσέ με αν δεν τα είπα καλά κάπου.

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 21:51:04 GMT

Θα πρέπει να πω οτι δεν καταλαβαίνω τι εννοείς ακριβώς λέγοντας connected mode....
Είναι κάποιο definition που δεν γνωρίζω...? οπότε δεν μπορώ να καταλάβω καλά τι έχεις στο μυαλό σου λέγοντας αυτό....
Μήπως εννοείς το statless level του internet? Αν ναι, εγώ δεν μιλάω για τέτοια εφαρμογή, αλλά μια C/S σε ένα LAN.

Μήπως εννοείς το isolation level...? αυτό δεν έχει να κάνει με το ADO ή το BDE ...Κλπ κλπ

Συμφωνώ με το Conflict Resolution. Πρέπει να πω όμως οτι έτσι που το θέτεις μοιάζει να είναι κάτι νεό....
Το Conflict Resolution είναι πάρα πολύ παλιό θέμα και δεν είναι μόνο θέμα του ADO, της νέας υλοποίησης, προσέγγισης, τεχνολογίας όπως θες πες το. Να σου θυμίσω (χαριτολογόντας) οτι όλοι χροοονια ψάχνουμε αυτόν τον "Another User" που συνέχεια κάνει change το row όσο εγώ κάνω αλλαγές.... βλέπε isolation level: Commited Read

Τα Client Datasets, τα ApplyUpdates σε Remote Datamodules (ορολογία Borland) κλπ κλπ υποστηρίζονται πάνω απο 10 χρόνια.

To πόσο είναι κάτι δεδομένο από τη στιγμή που διάβασες τα data μέχρι τη στιγμή που "αποφάσισες" να τα αλλάξεις δεν θα έλεγα οτι είναι θέμα ADO ή BDE, αλλά θέμα του Isolation Level που έχες επιλέξει.
Αν έχεις επιλέξει Dirty Read (π.χ. Select * from Table1 with(nolock) ) τότε αυτό που θα διαβάσεις δεν ξέρεις καν αν θα έχει γίνει commit, είτε δουλεύεις ADO είτε BDE είτε είτε είτε...

PS: Για να μην γίνει καμιά παρεξήγηση, μην νομίσει κάποιος οτι προσπαθώ να "περάσω" οτι η Borland έχει καλύτερη βιβλιοθήκη κλπ κλπ... άλλοστε αν πιστεύα 100% κάτι τέτοιο δεν θα είμουνα τώρα εδώ να κάνουμε αυτην την επικοδομιτική (πιστεύω) κουβέντα, ούτε θα σπαταλούσα τόσες ώρες για την τεχνολογία της MS.

Απ: Dynamic SQL generation is not supported against multiple base tables

KelMan — Fri, 12 Oct 2007 19:31:08 GMT

Επιπρόσθετα, να σου πω Thiseas ότι αυτό που περιγράφεις, υποστηρίζεται από το engine της Borland (αλλά και από το παλιό ADO της Microsoft) για έναν και μόνο λόγο. Αυτά τα engines δουλεύουν σε connected mode. Συνδέονται στη βάση, τραβάνε τα data και κλειδώνουν, οπότε είναι πολύ εύκολο να καταλάβουν τι αλλαγές έχουν συμβεί και να περάσουν πίσω τις ενημερώσεις. Στο ADO.NET υπάρχει τεράστια διαφορά καθώς υπάρχει το disconnected μοντέλο που καθιστά πολύ δυσκολότερη αυτή τη δουλειά και η δυσκολία εντοπίζεται στο ότι πρέπει να κάνεις conflict resolution μιας και δεν είναι τίποτα δεδομένο για την κατάσταση των data από τη στιγμή που τα διάβασες μέχρι τη στιγμή που τα ενημερώνεις.

Απ: Dynamic SQL generation is not supported against multiple base tables

KelMan — Fri, 12 Oct 2007 19:10:30 GMT

To 2003 που γράφτηκε αυτό το άρθρο *ίσως* (και πάλι με μεγάαααλη επιφύλαξη) ήταν μια καλή λύση η one-size-fits-all stored procedure. Σήμερα, με όλα αυτά τα frameworks και τα ORMs που κυκλοφορούν, δεν θα το έκανα με τίποτα...

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 17:40:05 GMT

Ψάχνοντας βρήκαμε ένα πολύ ενδιαφέρον άρθρο για το θέμα: http://msdn2.microsoft.com/en-us/library/ms971491.aspx

Παραθέτω ένα μικρό απόσπασμα:

Okay, so it's tough to use the CommandBuilder when your SELECT queries get a bit more complex. What can you use instead? Well, there are lots of alternatives. What I've been doing lately is getting the DACW to help. To start with, I usually use stored procedures to perform both the SELECT and action queries. To setup a Command object to execute a stored procedure, you set the CommandText to the name of the stored procedure and the CommandType to CommandType.StoredProcedure—pretty much like ADOc.

Απ: Dynamic SQL generation is not supported against multiple base tables

KelMan — Fri, 12 Oct 2007 15:48:33 GMT

Και στο .NET υπάρχει λύση. Για παράδειγμα το LLBLGen Pro, όταν έχει μια ιεραρχία από objects (πχ Customer με property collection από Orders που το κάθε Order έχει property με collection από OrderItems) παράγει τα κατάλληλα SQL Queries για CRUD operations. Εσύ απλά λες Fetch ή Update και όλα τα υπόλοιπα τα κάνει μόνο του Από εκεί και πέρα, ο builtin ADO.NET μηχανισμός δεν παρέχει αυτή τη δυνατότητα αλλά έτσι κι αλλιώς ο CommandBuilder sucks big time καθώς ο κώδικας που παράγει είναι πολύ inefficient.

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 05:40:14 GMT

Thnx για τις απαντήσεις, αλλά η εφαρμογή που το κάνει αυτό που ψάχνω σε .Net υπάρχει ήδη σε Delphi και δουλεύει αρκετά χρόνια,... απλά πρέπει να το μεταφέρω ή άλλες φορές να το ξαναγράψω.... σε C#.

Καλώς ή κακώς η λειτουργικότητα με τα "άγνωστα" SQL queries πρέπει να μείνει ως έχει για διάφορους λόγους.... απλά παραπονιέμαι λίγο γιατί η Borland (όπως ήδη είπα) το έχει κάνει ήδη....

Tespa....

Thnx 4 your time again...

Απ: Dynamic SQL generation is not supported against multiple base tables

George J. Capnias — Fri, 12 Oct 2007 04:50:15 GMT

Φοβάμαι ότι βλέπεις το πρόβλημα μονοδιάστατα!

Όπως είπες και εσύ, το SQL δεν το ξέρεις παρά μόνο την στιγμή που θα σχηματιστεί και θα ζητήσει να εκτελεστεί. Επειδή και να φτιάξεις ένα τέτοιο parser, την στιγμή που ένα ανθρώπινο μυαλό δεν θα μπορεί να μαντέψει ακριβώς το κυρίως table ενός query όπως θα το δει έτοιμο, πως θα μπορέσεις να υλοποιήσεις ένα parser να το κάνει; Δεν έχω ακούσει για έτοιμο τέτοιο parser - τέτοιας μορφής που να κάνει αυτή την δουλειά, και πιστεύω ότι θα είναι δύσκολο να υλοποιηθεί.

Οπότε σε συνέχεια των σκέψεων του Παναγιώτη, θα συνέχιζα ότι αυτό που θα πρέπει να υλοποιηθεί, θα μπορούσε να γίνει με βάση το αποτέλεσμα του query - να μπορέσεις να ξεχωρίσεις τα πεδία και τα tables από το αποτέλεσμα που θα επιστρέψει το query.

Μια δεύτερη λύση στο πρόβλημα, αντί να πάμε ένα βήμα μετά και να αναζητήσουμε στο αποτέλεσμα του query τη λύση στο πρόβλημά μας, να πάμε ένα βήμα πίσω, και αντί να συνθέσουμε το SQL μας με τον πατροπαράδοτο τρόπο του concatenating, να σχηματίσουμε μια κλάση, που θα μπορεί με στοιχεία τα ονόματα των πεδίων των tables που θέλουμε να μας φτιάχνει το επιθυμητό query, και αφού έχουμε μια μηχανή που θα φτιάχνει το SELECT query μας, πόσο δύσκολο είναι να της δώσουμε και ένα hint για το κύριο table ώστε να μπορέσει με τα ίδια στοιχεία να φτιάξει και τα INSERT/UPDATE/DELETE queries;

Έχοντας υλοποιήσει παρόμοιο μηχανισμό με το δεύτερο που περιγράφω, πιστεύω ότι είναι ο πιο στρωτός και σίγουρος δρόμος, και με εξασφαλισμένο το αποτέλεσμα και θα σου πρότεινα να τον ακολουθήσεις...

George J.

Απ: Dynamic SQL generation is not supported against multiple base tables

Thiseas — Fri, 12 Oct 2007 03:10:46 GMT

Χμ.... ναι σωστές όλες οι παρατηρήσεις.

Σκεφτείτε όμως οτι υπάρχει ένας πίνακας ο οποίος γεμίζει με SQL statements δυναμικά, τα οποία δεν τα γνωρίζω από πριν, παρά μόνο στο runtime.
Αυτά τα Select statements συνδέονται δυναμικά με ένα data grid στο οποίο (ακόμα και μένα απλό join), δεν μπορω να κάνω update....

Φοβάμαι οτι τον parser δεν τον "γλυτώνουμε"...

Απ: Dynamic SQL generation is not supported against multiple base tables

Παναγιώτης Καναβός — Fri, 12 Oct 2007 02:42:58 GMT

Ακόμα και η απλή περίπτωση των πινάκων Χ, Υ, Ζ δεν είναι καθόλου απλή. Γιατί να θεωρούμε ότι ο Χ είναι ο βασικός πίνακας? Η σειρά των πινάκων σε ένα join δεν παίζει κανένα ρόλο. Δεν είναι δυνατόν από τη σειρά των πινάκων ή το ότι κάποιοι συνδέονται με inner join, να συμπεράνει κανείς ότι ένας από αυτούς είναι βασικός. Άσε, που αν το join δεν είναι στα primary keys, όχι ποιός είναι ο σωστός πίνακας δεν μπορείς να ξέρεις, αλλά ούτε καν ποιό είναι το σωστό row. Το ADO 2.0 σου επέτρεπε μέσω διαφόρων properties να κάνεις updates σε πολύ περιορισμένες περιπτώσεις. Αυτό δεν πέρασε στο ADO.NET γιατί δεν χρειάζεται.

Υπάρχει απλούστερη λύση: Να φορτώσεις τους πίνακες σε ένα dataset, με το relation που θέλεις μεταξύ τους. Με τον τρόπο αυτό δεν υπάρχει καμμία ασάφεια ως προς το ποιοί πίνακες και ποιές γραμμές χρειάζονται updates. Άσε που έτσι φορτώνεις και σημαντικά λιγότερα δεδομένα.